Re: %changelog not in descending chronological order
On Tue, Jul 17, 2012 at 02:17:59AM +0200, Kacper Kornet wrote: > > > But that would be not 'totally unordered'. > > > GIT history is just not linear > > It's the different history: take %changelog as NEWS > > and commit messages as CHANGELOG. The latter is for > > developers while the former is for users (sysadmins). (at least that's my take at the problem, of course) > > And for a given package there's sense to make sure > > its git history *is* linear. > > See e.g. http://git.altlinux.org/gears/r/rpm.git > Could you elaborate a little more how do you do it? I write my %changelogs by hand since that allows me the luxury of proper commits with explanations regarding developer side (like if I was documenting things for myself reading it again a year or two later), *and* yet allows me the luxury of reading terse enough changelogs via rpm -q --lastchange :) > I see that changelog entries are still present in spec files, Yes; that's both good and bad, not sure if openSUSE or PLD approach wins for me (but it's only a personal opinion!). Generated data tend to be less useful due to lower SNR. There's a gear-commit(1) utility for doing the opposite, generating commit messages from %changelog records: http://docs.altlinux.org/manpages/gear-commit.1.html > and they are generated from commitlogs of tagged commits. Might be but not enforced to. > But how does these commitlogs are generated. Are they some > short of condensed 'git log' from the last tag? There's gear-changelog(1) utility developed for the storage format born at ALT some six or seven years ago: http://docs.altlinux.org/manpages/gear-changelog.1.html http://docs.altlinux.org/manpages/gear-changelog-rules.5.html http://www.altlinux.org/Gear/changelog [ru] Maybe it serves as a good starting point for PLD's one. Just in case, server side has girar- prefix: http://git.altlinux.org/people/ldv/packages/?s=girar > And how to you force that the tagged commits are in > chronological order? The next "buildable" tag has to inherit from the previous successfully built tag for the successfully built new package to be allowed through to the repository. There's considerable work by Alexey Tourbin in place regarding the repository consistency, I can give a link to a whitepaper in Russian (proshu pana). DISCLAIMER: there are some troubles with the (almost) free-form git repos that gear supports for package generation; if interested, I can try to sum these up. In short, getting a repo into a state when no sane Patch: series could be extracted and stored in srpm is pretty easy, it's enough to be lazy and fix things in-place... (ALT used to be a meaningful source of patches but this got hit pretty heavily by megapatches or even %name-%version-%release.tar files incorporating all the upstream code and patches/commits in nearby git branches). And that's a problem. By the way, *thank you* PLD folks for your nice specs with predictable URLs as well as for nice standalone patches. -- WBR, Michael Shigorin -- Linux.Kiev http://www.linux.kiev.ua/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Tue, Jul 17, 2012 at 01:54:40AM +0300, Michael Shigorin wrote: > On Tue, Jul 17, 2012 at 12:02:58AM +0200, Jacek Konieczny wrote: > > But that would be not 'totally unordered'. > > GIT history is just not linear > It's the different history: take %changelog as NEWS > and commit messages as CHANGELOG. The latter is for > developers while the former is for users (sysadmins). > And for a given package there's sense to make sure > its git history *is* linear. > See e.g. http://git.altlinux.org/gears/r/rpm.git > (which is an archived version of what got into packages > built -- while individual maintainers can have widely > different intermediate trees published, the inheritance > is enforced by the build system). Could you elaborate a little more how do you do it? I see that changelog entries are still present in spec files, and they are generated from commitlogs of tagged commits. But how does these commitlogs are generated. Are they some short of condensed 'git log' from the last tag? And how to you force that the tagged commits are in chronological order? -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Mon, Jul 16, 2012 at 03:47:41PM -0400, Jeffrey Johnson wrote: > On Jul 16, 2012, at 3:43 PM, Kacper Kornet wrote: > > On Mon, Jul 16, 2012 at 06:38:10PM +0200, Jacek Konieczny wrote: > >> On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: > >>> On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: > > That can be because 'git rev-list', used to generate the changelog, > > returns the commits ordered by commit date and not the AuthorDate > >>> Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be > >>> easier than trying to figure out how to trick up git sewage. > >> I wonder if RPM really needs to enforce the changelog order. Would it > >> really hurt if it just allowed building a package with such seemingly > >> unordered entries? Will anything break if we just disable the test? > > So we have two solutions: > > a) Switch to show committer dates in changelog. It should be possible to > > show these dates should be in chronological order. > > Drawback: for commits migrated from CVS this date is set to some > > value =~ time of cvs->git migration > > b) Patch rpm in PLD to remove enforcing of chronological order in > > changelog. The patch seems trivial. > > I would go for b). > c) qsort the 3 change log tags That can be done during changelog generation in builder. But I don't think it is a right solution. In my opinion changelog should reflect the topological history of development. > b) will introduce some incompatibilities: for starters, > there's functionality already implemented to truncate > change log's by number/oldest that will break if you > just go unordered. Do you mean the one build/parseChangelog.c:addChangelog? It depends how the breakage is defined. I have just checked and it behaves as expected in case of the non chronological changelog. If %_changelog_truncate macro is set to a date it ommits only older commits. All newer one are included independent of their position in changelog. And I think in PLD %_changelog_truncat macro should be set to a number, not a date. And there is always a possibility that was used in PLD in CVS. Generate the text of the whole changelog as a single entry in changelog from rpm point of view. That way rpm always see only one revision and does not complain. -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Tue, Jul 17, 2012 at 12:02:58AM +0200, Jacek Konieczny wrote: > But that would be not 'totally unordered'. > GIT history is just not linear It's the different history: take %changelog as NEWS and commit messages as CHANGELOG. The latter is for developers while the former is for users (sysadmins). And for a given package there's sense to make sure its git history *is* linear. See e.g. http://git.altlinux.org/gears/r/rpm.git (which is an archived version of what got into packages built -- while individual maintainers can have widely different intermediate trees published, the inheritance is enforced by the build system). -- WBR, Michael Shigorin -- Linux.Kiev http://www.linux.kiev.ua/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Mon, Jul 16, 2012 at 03:47:41PM -0400, Jeffrey Johnson wrote: > b) will introduce some incompatibilities: for starters, > there's functionality already implemented to truncate > change log's by number/oldest that will break if you > just go unordered. But that would be not 'totally unordered'. GIT history is just not linear, so there is no 'one real chronological order'. What is currently generated is enough for such features like 'truncate to last X entries', it is just not 'chronological enough' for RPM. RPM doing the sorting may in fact break the history – RPM does not know full history from the short git log excerpts. E.g. an old commit (made long time ago on a development branch) just recently added to the master branch could be moved past the truncation point. I also think that patching RPM may be the best choice here – easy and effective. Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Jul 16, 2012, at 3:43 PM, Kacper Kornet wrote: > On Mon, Jul 16, 2012 at 06:38:10PM +0200, Jacek Konieczny wrote: >> On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: >>> On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: > > > That can be because 'git rev-list', used to generate the changelog, > returns the commits ordered by commit date and not the AuthorDate > > >>> Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be >>> easier than trying to figure out how to trick up git sewage. > >> I wonder if RPM really needs to enforce the changelog order. Would it >> really hurt if it just allowed building a package with such seemingly >> unordered entries? Will anything break if we just disable the test? > > So we have two solutions: > > a) Switch to show committer dates in changelog. It should be possible to > show these dates should be in chronological order. > > Drawback: for commits migrated from CVS this date is set to some > value =~ time of cvs->git migration > > b) Patch rpm in PLD to remove enforcing of chronological order in > changelog. The patch seems trivial. > > I would go for b). > c) qsort the 3 change log tags d) rip out change logs from *.rpm entirely Unlike git scripting, any of b), c), f) are quite tricky. b) will introduce some incompatibilities: for starters, there's functionality already implemented to truncate change log's by number/oldest that will break if you just go unordered. hth 73 de Jeff > -- > Kacper > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Mon, Jul 16, 2012 at 06:38:10PM +0200, Jacek Konieczny wrote: > On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: > > On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: > > >> That can be because 'git rev-list', used to generate the changelog, > > >> returns the commits ordered by commit date and not the AuthorDate > > Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be > > easier than trying to figure out how to trick up git sewage. > I wonder if RPM really needs to enforce the changelog order. Would it > really hurt if it just allowed building a package with such seemingly > unordered entries? Will anything break if we just disable the test? So we have two solutions: a) Switch to show committer dates in changelog. It should be possible to show these dates should be in chronological order. Drawback: for commits migrated from CVS this date is set to some value =~ time of cvs->git migration b) Patch rpm in PLD to remove enforcing of chronological order in changelog. The patch seems trivial. I would go for b). -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Mon, Jul 16, 2012 at 12:41:55PM -0400, Jeffrey Johnson wrote: > (aside) > The ordering constraint was likely a quick hack to detect > time issues on an alpha miata (knowing almost all of RPM's hysteria). Well it does help detect some mismerges... -- WBR, Michael Shigorin -- Linux.Kiev http://www.linux.kiev.ua/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Jul 16, 2012, at 12:38 PM, Jacek Konieczny wrote: > On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: >> On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: >> >>> That can be because 'git rev-list', used to generate the changelog, returns the commits ordered by commit date and not the AuthorDate >>> >> >> Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be >> easier than trying to figure out how to trick up git sewage. > > I wonder if RPM really needs to enforce the changelog order. Would it > really hurt if it just allowed building a package with such seemingly > unordered entries? Will anything break if we just disable the test? > Yes loss of "legacy compatibility" would hurt with unordered entries. Nothing would break if all change log entries were ripped out either. (aside) The ordering constraint was likely a quick hack to detect time issues on an alpha miata (knowing almost all of RPM's hysteria). 73 de Jeff > Greets, >Jacek > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: > On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: > > > > >> That can be because 'git rev-list', used to generate the changelog, > >> returns the commits ordered by commit date and not the AuthorDate > > > > Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be > easier than trying to figure out how to trick up git sewage. I wonder if RPM really needs to enforce the changelog order. Would it really hurt if it just allowed building a package with such seemingly unordered entries? Will anything break if we just disable the test? Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: > >> That can be because 'git rev-list', used to generate the changelog, >> returns the commits ordered by commit date and not the AuthorDate > Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be easier than trying to figure out how to trick up git sewage. Its likely worth the modest additional effort to run change log text through iconv(3) and avoid encoding configuration issues. hth 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Thu, Jul 12, 2012 at 10:49:45AM +0200, Jacek Konieczny wrote: > Hi, > > [jajcus@jajo rpm-build-tools]$ ../builder -bb rpm-build-tools.spec > > builder: SMP make flags are set to -j1 > > Already up-to-date. > > Available branches: AC-brach AC-branch DEVEL LIBCHAMPLAIN_0_8 > > NEW_PEAR_REQUIRES PATCH_MD5 PLD RA-branch master niceprint rpm-4_1-15_1 > > rpm-4_4_3 rpm-4_4_6 rpm-4_4_7 rpm_files/master tag_checking > > Building target platforms: i686-linux > > error: %changelog not in descending chronological order > > Error: package build failed. (no more info) > I have examined the generated changelog in the temporary spec file and indeed: > > %changelog > > * Wed Jul 11 2012 Kacper Kornet c9933bf > > Add help message explaining how to push branch for the first time > > [...] > > * Wed Jul 11 2012 Kacper Kornet ace99bc > > Check for existence of tag during tagging > > * Tue Jul 10 2012 Kacper Kornet 8b6d179 > > tag_exist accepts preexisting tag pointing to HEAD > > * Wed Jul 11 2012 Kacper Kornet c9100f1 > > Simplify code in tag_files as TAGVER and TAG are mutually exclusive > > [...] > That can be because 'git rev-list', used to generate the changelog, > returns the commits ordered by commit date and not the AuthorDate A little more complicated. Even if the commit dates were the same as the author dates but parent - child relations were still the same, this three commits would be returned in by git rev-list in the same order. And the reason for order of this commit is that I developed them in order: 8b6d179 c9100f1 ace99bc and then before push change their order with git rebase -i to keep related commits close to each other. In the meantime the UTC midnight has passed so here is the result. But you are right, that probably --date-order should be used. It wouldn't change the order in changelog in this situation, but it others it can. > (and we want AuthorDate in the changelog)??? My logic was: the author not commiitter is shown, therefore the author date is also shown. -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On 12.07.2012 11:49, Jacek Konieczny wrote: I have examined the generated changelog in the temporary spec file and indeed: i noticed this too for package where i cherry-picked commits and pushed in one go (php package) also likely happens with branch merges (like draenog change there) -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
%changelog not in descending chronological order
Hi, > [jajcus@jajo rpm-build-tools]$ ../builder -bb rpm-build-tools.spec > builder: SMP make flags are set to -j1 > Already up-to-date. > Available branches: AC-brach AC-branch DEVEL LIBCHAMPLAIN_0_8 > NEW_PEAR_REQUIRES PATCH_MD5 PLD RA-branch master niceprint rpm-4_1-15_1 > rpm-4_4_3 rpm-4_4_6 rpm-4_4_7 rpm_files/master tag_checking > Building target platforms: i686-linux > error: %changelog not in descending chronological order > Error: package build failed. (no more info) I have examined the generated changelog in the temporary spec file and indeed: > %changelog > * Wed Jul 11 2012 Kacper Kornet c9933bf > Add help message explaining how to push branch for the first time > > [...] > * Wed Jul 11 2012 Kacper Kornet ace99bc > Check for existence of tag during tagging > > * Tue Jul 10 2012 Kacper Kornet 8b6d179 > tag_exist accepts preexisting tag pointing to HEAD > > * Wed Jul 11 2012 Kacper Kornet c9100f1 > Simplify code in tag_files as TAGVER and TAG are mutually exclusive > [...] That can be because 'git rev-list', used to generate the changelog, returns the commits ordered by commit date and not the AuthorDate (and we want AuthorDate in the changelog)… Does this work for anybody else? If so, what should I change? Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
