I gather I'm expected to write the changelog in a spec file by hand. How strict are the requirements on the format of changelog entries? Are they meant to be machine-readable? Is the format specified anywhere? The packaging guidelines document contains four examples. Examples are good but they're no replacement for a specification.
So far, RPMlint has told me that each entry must start with an asterisk and that the international standard date format is bad. Can I trust that the format is OK if RPMlint doesn't complain?
Björn Persson
On Sun, 19 Apr 2009, Björn Persson wrote:
I gather I'm expected to write the changelog in a spec file by hand. How strict are the requirements on the format of changelog entries?
RPMlint should be your friend. It yells at you if you do something wrong.
Are they meant to be machine-readable? (...) So far, RPMlint has told me that each entry must start with an asterisk and that the international standard date format is bad. Can I trust that the format is OK if RPMlint doesn't complain?
Should be so I think, since RPMlint is a machine, it's definately supposed to be machine-readable anyway since RPMlint is something we support.
There is also an RPM spec edit mode in Eclipse that Red Hat guys put in at some point I think, it should format the log according to some rules too.
But you're right: I've never seen a spec for this log either.
Linus
On Mon, 20 Apr 2009 10:52:57 +0200, Felix wrote:
Am 19.04.2009 23:32, schrieb Björn Persson:
I gather I'm expected to write the changelog in a spec file by hand.
Well you could start using rpmdev-bumpspec.
Emacs/XEmacs users can use M-x rpm-add-change-log-entry as provided by rpmdevtools.
On Mon, Apr 20, 2009 at 7:55 PM, Michael Schwendt mschwendt@gmail.com wrote:
Emacs/XEmacs users can use M-x rpm-add-change-log-entry as provided by rpmdevtools.
vim users can use <LocalLeader>-c (without needing rpmdevtools - and come nowhere close to "accidentally" hitting ctrl-alt-del)
On Monday 20 April 2009, Iain Arnell wrote:
On Mon, Apr 20, 2009 at 7:55 PM, Michael Schwendt mschwendt@gmail.com
wrote:
Emacs/XEmacs users can use M-x rpm-add-change-log-entry as provided by rpmdevtools.
vim users can use <LocalLeader>-c (without needing rpmdevtools
Small correction: Emacs/XEmacs users don't need rpmdevtools for that either - it's rpm-spec-mode.el which provides that functionality (shipped in the emacs and xemacs-packages-extra packages in Fedora).
What rpmdevtools does for *Emacs users is that it makes opening a new $foo.spec automatically use the corresponding rpmdevtools spec template for $foo as emitted by rpmdev-newspec, and adjusts a few more or less cosmetic variables. If there's a way to do something similar with vim (which currently appears to be using always the same template shipped in vim-common regardless of $foo) or other editors, patches are welcome in Bugzilla or fedorahosted.org/rpmdevtools
- and come nowhere close to "accidentally" hitting ctrl-alt-del)
Hmm, "Ctrl-c Ctrl-e"... phew!
On Mon, Apr 20, 2009 at 8:45 PM, Ville Skyttä ville.skytta@iki.fi wrote:
What rpmdevtools does for *Emacs users is that it makes opening a new $foo.spec automatically use the corresponding rpmdevtools spec template for $foo as emitted by rpmdev-newspec, and adjusts a few more or less cosmetic variables. If there's a way to do something similar with vim (which currently appears to be using always the same template shipped in vim-common regardless of $foo) or other editors, patches are welcome in Bugzilla or fedorahosted.org/rpmdevtools
would probably want to be a patch against vim rather than rpmdevtools since that's where the rest of the spec stuff is at the minute. Something like this maybe?
Index: vimrc =================================================================== RCS file: /cvs/pkgs/rpms/vim/devel/vimrc,v retrieving revision 1.20 diff -u -r1.20 vimrc --- vimrc 3 Jun 2008 14:34:32 -0000 1.20 +++ vimrc 21 Apr 2009 14:32:53 -0000 @@ -25,7 +25,11 @@ " don't write swapfile on most commonly used directories for NFS mounts or USB sticks autocmd BufNewFile,BufReadPre /media/*,/mnt/* set directory=~/tmp,/var/tmp,/tmp " start with spec file template - autocmd BufNewFile *.spec 0r /usr/share/vim/vimfiles/template.spec + if executable("rpmdev-newspec") + autocmd BufNewFile *.spec exe "rpmdev-newspec -o - ".bufname("%") + else + autocmd BufNewFile *.spec 0r /usr/share/vim/vimfiles/template.spec + endif augroup END endif
On Tuesday 21 April 2009 15:42:36 Iain Arnell wrote:
- autocmd BufNewFile *.spec 0r /usr/share/vim/vimfiles/template.spec
- if executable("rpmdev-newspec")
- autocmd BufNewFile *.spec exe "rpmdev-newspec -o - ".bufname("%")
- else
- autocmd BufNewFile *.spec 0r /usr/share/vim/vimfiles/template.spec
Please don't make vim do yet another bunch of stat() calls at startup to look for this </whine>
On Tuesday 21 April 2009, Bill Crawford wrote:
On Tuesday 21 April 2009 15:42:36 Iain Arnell wrote:
- autocmd BufNewFile *.spec 0r /usr/share/vim/vimfiles/template.spec
- if executable("rpmdev-newspec")
- autocmd BufNewFile *.spec exe "rpmdev-newspec -o - ".bufname("%")
- else
- autocmd BufNewFile *.spec 0r /usr/share/vim/vimfiles/template.spec
Please don't make vim do yet another bunch of stat() calls at startup to look for this </whine>
The above doesn't seem to be working for me ("E492: Not an editor command: rpmdev-newspec -o - foo.spec") but if someone can tweak vim to simply always use the stdout of (pseudocode):
rpmdev-newspec -o - bufname("%") 2>/dev/null || cat /usr/share/vim/vimfiles/template.spec
... for new *.spec I think that'd accomplish it without adding any startup burden.
On Tuesday 21 April 2009, Bill Crawford wrote:
Please don't make vim do yet another bunch of stat() calls at startup to look for this </whine>
for me running "vim perl-test.spec", before = 271 stat() calls; after = 279.
On Tue, Apr 21, 2009 at 6:25 PM, Ville Skyttä ville.skytta@iki.fi wrote:
The above doesn't seem to be working for me ("E492: Not an editor command: rpmdev-newspec -o - foo.spec")
my bad - serves me right for testing with both /etc/vimrc and ~/.vimrc and not diffing the right one. Should, of course, be
- autocmd BufNewFile *.spec exe "%!rpmdev-newspec -o - ".bufname("%")
On Tuesday 21 April 2009 21:05:00 Iain Arnell wrote:
On Tuesday 21 April 2009, Bill Crawford wrote:
Please don't make vim do yet another bunch of stat() calls at startup to look for this </whine>
for me running "vim perl-test.spec", before = 271 stat() calls; after = 279.
Hah. That'll teach me :o)
I still think it is better to reduce the impact in cases where something won't be used, though, i.e. the 98% of the time I'm not editing a .spec file.
But it looks like this one is more of a drop in the ocean than I'd realised.
Am 20.04.2009 20:23, schrieb Iain Arnell:
On Mon, Apr 20, 2009 at 7:55 PM, Michael Schwendtmschwendt@gmail.com wrote:
Emacs/XEmacs users can use M-x rpm-add-change-log-entry as provided by rpmdevtools.
vim users can use<LocalLeader>-c (without needing rpmdevtools - and come nowhere close to "accidentally" hitting ctrl-alt-del)
Some additional info on this... I have this in my .vimrc: let g:packager = "Karsten Hopp karsten@redhat.com" let g:spec_chglog_release_info = 1
As vim figures out the nvr automatically, the usual steps are - bump release - edit whatever in the spec file - <LocalLeader>-c - enter changelog text
This gets you a valid changelog entry with the correct date and nvr
Karsten
-- The main difference between vi and emacs is that someone who runs vi the first time, is unable to quit it, while someone who runs emacs the first time, is unable to quit it.
2009/4/19 Björn Persson bjorn@xn--rombobjrn-67a.se:
I gather I'm expected to write the changelog in a spec file by hand. How strict are the requirements on the format of changelog entries? Are they meant to be machine-readable? Is the format specified anywhere? The packaging guidelines document contains four examples. Examples are good but they're no replacement for a specification.
So far, RPMlint has told me that each entry must start with an asterisk and that the international standard date format is bad. Can I trust that the format is OK if RPMlint doesn't complain?
Björn Persson
Check out the packaging guidelines:
http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
On Mon, 20 Apr 2009 13:23:31 +0100, Mat wrote:
2009/4/19 Björn Persson:
I gather I'm expected to write the changelog in a spec file by hand. How strict are the requirements on the format of changelog entries? Are they meant to be machine-readable? Is the format specified anywhere? The packaging guidelines document contains four examples. Examples are good but they're no replacement for a specification.
So far, RPMlint has told me that each entry must start with an asterisk and that the international standard date format is bad. Can I trust that the format is OK if RPMlint doesn't complain?
Björn Persson
Check out the packaging guidelines:
http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
Which is what the OP commented on in the first chapter quoted above.
Most important, rpmbuild parses the %changelog section of a spec file and throws several error messages at you if it runs into trouble. For example, these fatal ones:
error: %changelog entries must start with * error: %changelog not in descending chronological order error: bad date in %changelog: ...
On Sun, 2009-04-19 at 23:32 +0200, Björn Persson wrote:
I gather I'm expected to write the changelog in a spec file by hand.
Why is this, BTW? Is there a reason we don't just generate it from CVS commit messages, beyond "no-one's had time / inclination to implement it"?
On 04/20/2009 10:21 AM, Adam Williamson wrote:
On Sun, 2009-04-19 at 23:32 +0200, Björn Persson wrote:
I gather I'm expected to write the changelog in a spec file by hand.
Why is this, BTW? Is there a reason we don't just generate it from CVS commit messages, beyond "no-one's had time / inclination to implement it"?
Because there's no forced standard for CVS commit messages. Plus, each CVS commit in pkgcvs does not necessarily equal a new release or version increment in the package. At least that's not how I use pkgcvs.
I view the RPM changelog as mostly fluff for end-user consumption. We [the packagers] can summarize the main points of that release, note bug numbers addressed, and other major points for that iteration of the package.
David Cantrell wrote:
On 04/20/2009 10:21 AM, Adam Williamson wrote:
On Sun, 2009-04-19 at 23:32 +0200, Björn Persson wrote:
I gather I'm expected to write the changelog in a spec file by hand.
Why is this, BTW? Is there a reason we don't just generate it from CVS commit messages, beyond "no-one's had time / inclination to implement it"?
Because there's no forced standard for CVS commit messages. Plus, each CVS commit in pkgcvs does not necessarily equal a new release or version increment in the package. At least that's not how I use pkgcvs.
I view the RPM changelog as mostly fluff for end-user consumption. We [the packagers] can summarize the main points of that release, note bug numbers addressed, and other major points for that iteration of the package.
I use rpm's changelog the way David does. I consider the one in the RPM to be the formal, end-user-facing record. The CVS changelog is where things like "EVR bump for chainbuild", "Fixed typo in summary" or "Shit, forgot a BuildRequires" go.
On Mon, 2009-04-20 at 15:29 -0500, Jon Ciesla wrote:
David Cantrell wrote:
I view the RPM changelog as mostly fluff for end-user consumption. We [the packagers] can summarize the main points of that release, note bug numbers addressed, and other major points for that iteration of the package.
I use rpm's changelog the way David does. I consider the one in the RPM to be the formal, end-user-facing record. The CVS changelog is where things like "EVR bump for chainbuild", "Fixed typo in summary" or "Shit, forgot a BuildRequires" go.
I don't know how official the guideline at http://fedoraproject.org/wiki/PackageMaintainers/Join is, but it states that the CVS changelog format is the same as for the spec file changelog.
The CVS changelog is indeed a bit redundant since everything important is already in the spec changelog, thus it might be used in a freer fashion.
Jussi Lehtola wrote:
I don't know how official the guideline at http://fedoraproject.org/wiki/PackageMaintainers/Join is, but it states that the CVS changelog format is the same as for the spec file changelog.
Well, I paste in the spec file changelog in most cases, but for something like "fix typo", I'll use freeform sentences in the CVS log and write nothing into the changelog (unless the typo was bad enough to warrant building a new release just to fix the typo, then of course I have to write why I made the new release). (This seems to be pretty close to what David Cantrell and Jon Ciesla also do, based on their comments.)
Of course I could commit with a blank commit message, then it'd match the specfile changelog exactly, but blank commit messages suck, they should be banned from the face of the Earth!
Kevin Kofler
On Mon, 2009-04-20 at 10:26 -1000, David Cantrell wrote:
On 04/20/2009 10:21 AM, Adam Williamson wrote:
On Sun, 2009-04-19 at 23:32 +0200, Björn Persson wrote:
I gather I'm expected to write the changelog in a spec file by hand.
Why is this, BTW? Is there a reason we don't just generate it from CVS commit messages, beyond "no-one's had time / inclination to implement it"?
Because there's no forced standard for CVS commit messages. Plus, each CVS commit in pkgcvs does not necessarily equal a new release or version increment in the package. At least that's not how I use pkgcvs.
It doesn't have to - you can generate the changelog as part of the package submission process, containing all the commit messages since the last package build.
I view the RPM changelog as mostly fluff for end-user consumption. We [the packagers] can summarize the main points of that release, note bug numbers addressed, and other major points for that iteration of the package.
You can have a keyword that you put in CVS commit messages that suppresses them from being added to the RPM changelog, if they wouldn't be useful in that context (like "rebuilt with no changes for some procedural reason").
(The win of doing things this way, btw, is that it saves maintainers time and effort, reduces errors introduced by the manual creation of what should be boilerplate content, and makes it less likely that important information will be left out of RPM changelogs, since you have to have a commit message and most developers habitually write useful ones).
On 04/20/2009 11:18 AM, Adam Williamson wrote:
On Mon, 2009-04-20 at 10:26 -1000, David Cantrell wrote:
On 04/20/2009 10:21 AM, Adam Williamson wrote:
On Sun, 2009-04-19 at 23:32 +0200, Björn Persson wrote:
I gather I'm expected to write the changelog in a spec file by hand.
Why is this, BTW? Is there a reason we don't just generate it from CVS commit messages, beyond "no-one's had time / inclination to implement it"?
Because there's no forced standard for CVS commit messages. Plus, each CVS commit in pkgcvs does not necessarily equal a new release or version increment in the package. At least that's not how I use pkgcvs.
It doesn't have to - you can generate the changelog as part of the package submission process, containing all the commit messages since the last package build.
But that's the thing I don't really want in the RPM changelog. All of the commit messages since the last package build are mostly noise to the average user.
I view the RPM changelog as mostly fluff for end-user consumption. We [the packagers] can summarize the main points of that release, note bug numbers addressed, and other major points for that iteration of the package.
You can have a keyword that you put in CVS commit messages that suppresses them from being added to the RPM changelog, if they wouldn't be useful in that context (like "rebuilt with no changes for some procedural reason").
(The win of doing things this way, btw, is that it saves maintainers time and effort, reduces errors introduced by the manual creation of what should be boilerplate content, and makes it less likely that important information will be left out of RPM changelogs, since you have to have a commit message and most developers habitually write useful ones).
You don't have to sell me on the idea, I do like it. But it should have been implemented when pkgcvs was created. As it stands, there are far too many garbage commit messages in pkgcvs now and far too much useful information in the rpm changelogs.
I think this problem would be better solved in a larger 'moving pkgcvs to some other vcs' discussion.
On Mon, 2009-04-20 at 13:21 -0700, Adam Williamson wrote:
Why is this, BTW? Is there a reason we don't just generate it from CVS commit messages, beyond "no-one's had time / inclination to implement it"?
Because we do it the other way around. 'make clog && cvs commit -F clog' Use the rpm changelog for cvs.
On Mon, 2009-04-20 at 15:15 -0700, Jesse Keating wrote:
On Mon, 2009-04-20 at 13:21 -0700, Adam Williamson wrote:
Why is this, BTW? Is there a reason we don't just generate it from CVS commit messages, beyond "no-one's had time / inclination to implement it"?
Because we do it the other way around. 'make clog && cvs commit -F clog' Use the rpm changelog for cvs.
so you manually write the one with extra bumph that could easily be automatically generated, and then use that to produce the one which *doesn't* have extra bumph that could easily be automatically generated? :)
On Mon, 2009-04-20 at 16:18 -0700, Adam Williamson wrote:
so you manually write the one with extra bumph that could easily be automatically generated, and then use that to produce the one which *doesn't* have extra bumph that could easily be automatically generated? :)
I'm not sure I follow. CVS sort of lends itself to doing a days worth of changes in one commit, so it's work work work, documenting work as you go in the .spec file (although often it's just "new upstream release" or "patch for $foo", then when you're ready to make it happen it's "make clog && cvs commit -F clog && make tag build"
Now if we were using a scm that was more geared toward commit as you go, we might consider something different, but even then what you want to expose to users isn't necessarily the same thing you want to document when doing SCM commits. Here is where git is neat with the shortlog, where you oneline your change, but then can expand upon it in another paragraph that will be seen when looking at the git log, but won't be seen if you do a simple short log (like say for stuffing in a .spec file).
On Mon, 2009-04-20 at 18:16 -0700, Jesse Keating wrote:
On Mon, 2009-04-20 at 16:18 -0700, Adam Williamson wrote:
so you manually write the one with extra bumph that could easily be automatically generated, and then use that to produce the one which *doesn't* have extra bumph that could easily be automatically generated? :)
I'm not sure I follow. CVS sort of lends itself to doing a days worth of changes in one commit, so it's work work work, documenting work as you go in the .spec file (although often it's just "new upstream release" or "patch for $foo", then when you're ready to make it happen it's "make clog && cvs commit -F clog && make tag build"
Now if we were using a scm that was more geared toward commit as you go, we might consider something different, but even then what you want to expose to users isn't necessarily the same thing you want to document when doing SCM commits. Here is where git is neat with the shortlog, where you oneline your change, but then can expand upon it in another paragraph that will be seen when looking at the git log, but won't be seen if you do a simple short log (like say for stuffing in a .spec file).
OK, I see what you're driving at now. But you missed one point I wrote on the issue of where you want the two to be different - you can just implement a keyword for commit messages which causes it not to go into the RPM changelog, viz:
cvs commit -m "this commit message will go into the RPM changelog" cvs commit -m "SILENT: but this one won't!"
pretty simple.
However, now I get your point, I agree that the issue of switching SCMs would be more significant and an appropriate place to look at this issue too. CVS is pretty creaky these days.
FWIW, when I was working on packages at That Other Place, I would work work work all day and then commit too, but with a commit message that looked like this:
- one change - another change - yet another change - SILENT: a trivial change i don't want to go in the RPM changelog
and that all got parsed correctly into the RPM changelog, in the way you'd expect it to.
2009/4/21 Adam Williamson awilliam@redhat.com:
OK, I see what you're driving at now. But you missed one point I wrote on the issue of where you want the two to be different - you can just implement a keyword for commit messages which causes it not to go into the RPM changelog, viz:
cvs commit -m "this commit message will go into the RPM changelog" cvs commit -m "SILENT: but this one won't!"
pretty simple.
How do you actually automatically generate the spec file changelog entry from the commit methods? [I've been using the make clog method, and actively hating it].
Cheers, J.
On Wed, 2009-04-22 at 12:31 +0100, Jonathan Underwood wrote:
2009/4/21 Adam Williamson awilliam@redhat.com:
OK, I see what you're driving at now. But you missed one point I wrote on the issue of where you want the two to be different - you can just implement a keyword for commit messages which causes it not to go into the RPM changelog, viz:
cvs commit -m "this commit message will go into the RPM changelog" cvs commit -m "SILENT: but this one won't!"
pretty simple.
How do you actually automatically generate the spec file changelog entry from the commit methods? [I've been using the make clog method, and actively hating it].
I don't know, the Special Magic Box always did it for me =)
this is based on my experience at Mandriva - in that system, there's no changelog section at all in the spec file as stored in SVN (MDV stores specs and sources in an SVN server, much like Fedora uses CVS). When you submit a package to be built, at some point, the build tools generate the changelog entry from your commit messages for the build that actually gets generated and sent to the mirrors.
Give me half an hour and I'll poke through the bits of the buildsystem I still remember and see if I can find the code...
...
ah, right, it's in repsys. repsys source tarball is here: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/repsys/current/SO... , and it's done by RepSys/log.py .
Jesse Keating wrote:
Because we do it the other way around. 'make clog && cvs commit -F clog' Use the rpm changelog for cvs.
How I do it is that I just select my changelog entry in the editor (usually the embedded KatePart in Krusader, though sometimes I use the standalone KWrite or Kate), middle-click it into the textbox in Cervisia and click OK. :-)
Am I the only one using a CVS GUI around here?
Kevin Kofler
On Tue, 2009-04-21 at 04:47 +0200, Kevin Kofler wrote:
Jesse Keating wrote:
Because we do it the other way around. 'make clog && cvs commit -F clog' Use the rpm changelog for cvs.
How I do it is that I just select my changelog entry in the editor (usually the embedded KatePart in Krusader, though sometimes I use the standalone KWrite or Kate), middle-click it into the textbox in Cervisia and click OK. :-)
Am I the only one using a CVS GUI around here?
Heh. Interesting point. I've never used an SCM GUI system, but OTOH, I always do spec editing (and my limited level of hacking, and all other text editing) in gedit. =)
Björn Persson wrote:
I gather I'm expected to write the changelog in a spec file by hand. How strict are the requirements on the format of changelog entries? Are they meant to be machine-readable? Is the format specified anywhere? The packaging guidelines document contains four examples. Examples are good but they're no replacement for a specification.
The format is fairly straightforward:
* first line (elements separated by spaces): - asterisk - date in Wkd Mth dd yyyy format (e.g. Mon Apr 21 2009) (if the day is just 1 digit, you can write any of "1", " 1" or "01") - your name - your e-mail address between angle brackets ('<' and '>') - optionally a dash - the EVR (Epoch-Version-Release) of the package, without the disttag, e.g. 3.5.10-1 for 3.5.10-1.fc11, 3.5.10-1.1 for 3.5.10-1.fc11.1, 6:4.2.2-1 if the package has Epoch 6 (the Epoch is specified only if present and you use a ':' between Epoch and Version) * any other lines (elements separated by spaces): - dash (plain ASCII dash, please don't use some strange UTF-8 character) - text describing your change - if your change doesn't fit in one line, start a new line and indent it with 2 spaces, so it is aligned with the text above (which has a dash and a space) - bugs should be referenced as (#666666) (or, if there's any chance of confusion, (rh#666666)) for Fedora bugs and as (foo#666666), where foo is the relevant bug tracker (e.g. kde, sf, fdo etc.), for upstream bugs
Kevin Kofler
On Tue, 2009-04-21 at 03:25 +0200, Kevin Kofler wrote:
The format is fairly straightforward:
- first line (elements separated by spaces):
- asterisk
- date in Wkd Mth dd yyyy format (e.g. Mon Apr 21 2009) (if the day is just 1 digit, you can write any of "1", " 1" or "01")
- your name
- your e-mail address between angle brackets ('<' and '>')
- optionally a dash
- the EVR (Epoch-Version-Release) of the package, without the disttag, e.g. 3.5.10-1 for 3.5.10-1.fc11, 3.5.10-1.1 for 3.5.10-1.fc11.1, 6:4.2.2-1 if the package has Epoch 6 (the Epoch is specified only if present and you use a ':' between Epoch and Version)
- any other lines (elements separated by spaces):
- dash (plain ASCII dash, please don't use some strange UTF-8 character)
- text describing your change
- if your change doesn't fit in one line, start a new line and indent it with 2 spaces, so it is aligned with the text above (which has a dash and a space)
- bugs should be referenced as (#666666) (or, if there's any chance of confusion, (rh#666666)) for Fedora bugs and as (foo#666666), where foo is the relevant bug tracker (e.g. kde, sf, fdo etc.), for upstream bugs
( I have always been told that there should be one empty line between two entry :) )
Regards, Pierre
Pierre-Yves wrote:
On Tue, 2009-04-21 at 03:25 +0200, Kevin Kofler wrote:
The format is fairly straightforward:
- first line (elements separated by spaces):
- asterisk
- date in Wkd Mth dd yyyy format (e.g. Mon Apr 21 2009) (if the day is just 1 digit, you can write any of "1", " 1" or "01")
- your name
- your e-mail address between angle brackets ('<' and '>')
- optionally a dash
- the EVR (Epoch-Version-Release) of the package, without the disttag, e.g. 3.5.10-1 for 3.5.10-1.fc11, 3.5.10-1.1 for 3.5.10-1.fc11.1, 6:4.2.2-1 if the package has Epoch 6 (the Epoch is specified
only if present and you use a ':' between Epoch and Version)
- any other lines (elements separated by spaces):
- dash (plain ASCII dash, please don't use some strange UTF-8
character) - text describing your change
- if your change doesn't fit in one line, start a new line and indent
it with 2 spaces, so it is aligned with the text above (which has a dash and a space)
- bugs should be referenced as (#666666) (or, if there's any chance of confusion, (rh#666666)) for Fedora bugs and as (foo#666666), where
foo is the relevant bug tracker (e.g. kde, sf, fdo etc.), for upstream bugs
( I have always been told that there should be one empty line between two entry :) )
Thanks Kevin and Pierre, that's a good description. If I could edit the wiki I'd add that to the guidelines.
The dash at the start of "other" lines is one thing that RPMlint doesn't check.
Björn Persson
Pierre-Yves wrote:
( I have always been told that there should be one empty line between two entry :) )
Yes. To clarify, there should be an empty line between each block:
* ... - ... - ... ---- EMPTY LINE HERE --- * ... - ... - ...
There should be NO empty lines: * ... HERE - ... NOR HERE - ...
Kevin Kofler