# grep '^*' /usr/portage/xfce-extra/xfswitch-plugin/ChangeLog *xfswitch-plugin-0.0.1-r1 (09 Aug 2015) *xfswitch-plugin-0.0.1-r2 (14 Sep 2015) This is inverted to the previous state and very unusual for ChangeLogs.
Looks like this also broke the -l/--changelog option of emerge: # emerge -uDNpl @system @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-emulation/wine-1.7.55 [1.7.54-r1] *wine-9999 *wine-1.7.47 [... many lines omitted ...] *wine-1.7.54 15 Nov 2015; NP-Hardass <NP-Hardass@gentoo.org> +wine-1.7.54.ebuild, wine-9999.ebuild: Version bump to 1.7.54. Drop default prelink flag. Wine 1.7.54 adds a patch to use the system linker if possible before attempting to use prelink. As such, dropping default status for prelink. Hardened users are unable to take advantage of this and may still want to unmask and use the prelink flag, though this isn't well supported. Package-Manager: portage-2.2.23 That is, it now dumps the whole ChangeLog _except_ for the relevant entries.
Are you sure this is properly assigned? It could be a bug in egencache and, then, portage team would be the right people knowing about how to solve this :/
Well, I for one don't want to change the current setting in portage, gentoolkit or porthole until the egencache changelog code is settled and stable. It is in re-write mode by 3 people atm. Robin and dwfreed are rewriting the python code, Cardoe is working on an an all "C" Changelog generation app.
We may need a metadata/layout.conf setting that indicates whether the ChangeLogs are in chronological or reverse-chronological order.
yeah, that could be doable
Do we really need to state that explicitly when changelogs contain timestamps?
(In reply to Michał Górny from comment #6) > Do we really need to state that explicitly when changelogs contain > timestamps? It would be ambiguous if the ChangeLog only contains a single day's worth of history. I guess this case is negligible though. Generally, we can just compare the first and last date to determine the order.
(In reply to Zac Medico from comment #4) > We may need a metadata/layout.conf setting that indicates whether the > ChangeLogs are in chronological or reverse-chronological order. Why? Hardcode it to newest first and be done.
The point here is that the ChangeLog files themselves are wrongly ordered in the first place, not that emerge --changelog breaks when it is completely wrongly ordered. Almost all projects with ChangeLog entries are newest entries on top, and that's how it should be from gentoo rsyncs as well again. That is the issue here, not that --changelog is broken when the order is broken in the files. I do not use --changelog, but less the ChangeLog files and this bug alone is making me heavily consider dumping rsync mirrors and use anongit everywhere I don't need non-anon git.
The council has decided that ChangeLog files (if provided) must have newest entries first: https://projects.gentoo.org/council/meeting-logs/20160410-summary.txt - Vote: "The council does not require that ChangeLogs be generated or distributed through the rsync system. It is at the discretion of our infrastructure team whether or not this service continues." Accepted (4 yes, 1 no, 2 abstention) - Vote: "If ChangeLog files are provided, they must be in the order of newest entries first" Accepted (4 yes, 2 no, 1 abstention) Infra, please proceed with this.
ulm: I posted the infra plan to the lists, but for repeating here; I plan to discontinue the changelog distribution in their present form. They will be replaced by a separate rsync module that contains only changelogs (and can be rsync'd over the top of a rsync repo safely). It's pending having a good historical conversion of CVS->Git as it turns out the prior conversion missed an entire category (app-backup) for unknown reasons.
Ping. Two more months have passed, and I don't see any progress. (In reply to Robin Johnson from comment #11) > It's pending having a good historical conversion of CVS->Git [...] Why is this needed? Can't ChangeLogs be taken from the final CVS tree?
(In reply to Ulrich Müller from comment #12) > Ping. Two more months have passed, and I don't see any progress. > > (In reply to Robin Johnson from comment #11) > > It's pending having a good historical conversion of CVS->Git [...] > > Why is this needed? Can't ChangeLogs be taken from the final CVS tree? +1 I see the "good historical conversion" as a separate project. If it is desired, that is fine, but it should not be a blocker for this project.
Also, we're are now more than one year past the date of the Git migration, so ChangeLogs from the CVS era have become less important. I don't think that a slightly defective historical conversion (or even two missing categories) would be much of a problem there. IMHO, even dropping the ChangeLogs from the CVS era altogether would be justifiable. After all, the gentoo-x86 CVS repo is still available and they can be viewed there.
ChangeLogs are now excluded from the gentoo-portage rsync module. This weekend, I hope to roll out the flipped order of the ChangeLogs, if there are no problems reported for people not having ChangeLogs in their trees anymore.
(In reply to Robin Johnson from comment #15) > This weekend, I hope to roll out the flipped order of the ChangeLogs, if > there are no problems reported for people not having ChangeLogs in their > trees anymore. Polite reminder, as discussed in today's council meeting: <jlec> Changelog is oldest first <dilfridge> which is how we *not* wanted to have it, right? <ulm> jlec: it is indeed <ulm> rsync://rsync.gentoo.org/gentoo-repo-changelog <dilfridge> ok so maybe we should leave a comment / polite reminder on the bug then and stay in cc <blueness> yep, confirmed
Can this bug be closed? ChangeLogs are gone.
Changelogs in git are longer available. -A
