Hi,
As we disable the package database, there is one rather important change that I only figured the importance of today:
So far the spec files are rewritten to use the texts and attributes from the package database a) when checked in factory b) when building
Both steps will be disabled in the future, we still will do some formatting, but we won't take any attributes (AFAIK) so the spec file contains the master information.
So there are consequences out of this: 1) we have quite some spec files that haven't been checked in a while and as b) is disabled, they will use old informations when building. 2) we have quite some packages that are creating placeholders into summary and description and relying on a) to create useful spec files. This will no longer be the case.
For 1) I did some scripting to find out where the differences are if I would sr all packages _NOW_ (while pdb is still active). The list of changes is impressive, but I will filter out less important cases (e.g. where only the changelog is affected - as this will still be reformated in the future): http://www.suse.de/%7Ecoolo/spec_patches/ We may end up checkin in these diffs without spamming opensuse-commit, just so you know if your branched package broke (IMO it's very unlikely it will as this affects mostly packages without active development).
For 2) you need to act: if your spec file is generated from a vcs, then you need to merge texts and attributes back into the template. If you have a package using a script to generate the spec file, then you need to enhance the script.
Greetings, Stephan
Hi!
On Thu, Jun 18, 2009 at 01:51:59PM +0200, Stephan Kulow wrote:
For 2) you need to act: if your spec file is generated from a vcs, then you need to merge texts and attributes back into the template. If you have a package using a script to generate the spec file, then you need to enhance the script.
So how do I get osc to update my .spec file with the up-to-date data? 'osc up' alone won't do it, apparently. (At least the %changelog section is still out-of-date.) I can see just metafromspec for the other direction...
On Thursday 18 June 2009 16:00:43 Petr Baudis wrote:
Hi!
On Thu, Jun 18, 2009 at 01:51:59PM +0200, Stephan Kulow wrote:
For 2) you need to act: if your spec file is generated from a vcs, then you need to merge texts and attributes back into the template. If you have a package using a script to generate the spec file, then you need to enhance the script.
So how do I get osc to update my .spec file with the up-to-date data? 'osc up' alone won't do it, apparently. (At least the %changelog section is still out-of-date.) I can see just metafromspec for the other direction...
the build package has /usr/lib/build/changelog2spec
Greetings, Stephan
On Thu, 18 Jun 2009, Stephan Kulow wrote:
Hi,
As we disable the package database, there is one rather important change that I only figured the importance of today:
So far the spec files are rewritten to use the texts and attributes from the package database a) when checked in factory b) when building
Both steps will be disabled in the future, we still will do some formatting, but we won't take any attributes (AFAIK) so the spec file contains the master information.
So there are consequences out of this:
- we have quite some spec files that haven't been checked in a while and as
b) is disabled, they will use old informations when building. 2) we have quite some packages that are creating placeholders into summary and description and relying on a) to create useful spec files. This will no longer be the case.
For 1) I did some scripting to find out where the differences are if I would sr all packages _NOW_ (while pdb is still active). The list of changes is impressive, but I will filter out less important cases (e.g. where only the changelog is affected - as this will still be reformated in the future): http://www.suse.de/%7Ecoolo/spec_patches/ We may end up checkin in these diffs without spamming opensuse-commit, just so you know if your branched package broke (IMO it's very unlikely it will as this affects mostly packages without active development).
For 2) you need to act: if your spec file is generated from a vcs, then you need to merge texts and attributes back into the template. If you have a package using a script to generate the spec file, then you need to enhance the script.
Does this mean there will be another external authorative source for this kind of information in the future (thus, the .spec files will be edited automatically again)? Or can the local file that the .spec files are generated from be the "master" copy - in which case I don't see the need to enhance the scripts but only do a manual merge once?
Thanks, Richard.
On Thursday 18 June 2009 18:04:51 Richard Guenther wrote:
For 2) you need to act: if your spec file is generated from a vcs, then you need to merge texts and attributes back into the template. If you have a package using a script to generate the spec file, then you need to enhance the script.
Does this mean there will be another external authorative source for this kind of information in the future (thus, the .spec files will be edited automatically again)? Or can the local file that the .spec
They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
files are generated from be the "master" copy - in which case I don't see the need to enhance the scripts but only do a manual merge once?
That highly depends on what your script does I guess. I know that yast packages have "Summary: -" in their svn, I know that bundle-lang had "Summary: Summary" in the generated spec files, etc.
Greetings, Stephan
Le jeudi 18 juin 2009, à 19:45 +0200, Stephan Kulow a écrit :
On Thursday 18 June 2009 18:04:51 Richard Guenther wrote:
For 2) you need to act: if your spec file is generated from a vcs, then you need to merge texts and attributes back into the template. If you have a package using a script to generate the spec file, then you need to enhance the script.
Does this mean there will be another external authorative source for this kind of information in the future (thus, the .spec files will be edited automatically again)? Or can the local file that the .spec
They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
Is there any reason we put the changelog data in %changelog since the data is in .changes files?? Can't we just let it happen during the build and not have this in the spec files in the obs? This would make them much shorter, which would be a good thing, I think.
Vincent
On Fri, Jun 19, 2009 at 02:37, Vincent Untzvuntz@opensuse.org wrote:
Is there any reason we put the changelog data in %changelog since the data is in .changes files?? Can't we just let it happen during the build and not have this in the spec files in the obs? This would make them much shorter, which would be a good thing, I think.
+1
-Suman
Hi,
On Thu, 18 Jun 2009, Vincent Untz wrote:
Does this mean there will be another external authorative source for this kind of information in the future (thus, the .spec files will be edited automatically again)? Or can the local file that the .spec
They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
Is there any reason we put the changelog data in %changelog since the data is in .changes files??
No. If you did or do that, you're wasting time. %changelog was and will be rewritten from the content of .changes. We for instance never cared for %changelog sections in .spec files, only for .changes files. Simply leave the section empty (I'm not sure what happens if you leave it out alltogether, so just empty it).
Ciao, Michael.
Michael Matz wrote:
Hi,
On Thu, 18 Jun 2009, Vincent Untz wrote:
Does this mean there will be another external authorative source for this kind of information in the future (thus, the .spec files will be edited automatically again)? Or can the local file that the .spec
They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
Is there any reason we put the changelog data in %changelog since the data is in .changes files??
No. If you did or do that, you're wasting time. %changelog was and will be rewritten from the content of .changes. We for instance never cared for %changelog sections in .spec files, only for .changes files. Simply leave the section empty (I'm not sure what happens if you leave it out alltogether, so just empty it).
Right. If you leave it out, rpmlint will emit a warning. But I have another question: isn't now a good time to get rid off .changes files completely? (+adjusting tools like vc and osc)
Pavol Rusnak schrieb:
Michael Matz wrote:
Hi,
On Thu, 18 Jun 2009, Vincent Untz wrote:
Does this mean there will be another external authorative source for this kind of information in the future (thus, the .spec files will be edited automatically again)? Or can the local file that the .spec
They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
Is there any reason we put the changelog data in %changelog since the data is in .changes files??
No. If you did or do that, you're wasting time. %changelog was and will be rewritten from the content of .changes. We for instance never cared for %changelog sections in .spec files, only for .changes files. Simply leave the section empty (I'm not sure what happens if you leave it out alltogether, so just empty it).
Right. If you leave it out, rpmlint will emit a warning. But I have another question: isn't now a good time to get rid off .changes files completely? (+adjusting tools like vc and osc)
Hum, why? I very much prefer the *.changes files about the changelog in the spec file. Why would you want to change that?
Wolfgang
Wolfgang Rosenauer wrote:
Pavol Rusnak schrieb:
Michael Matz wrote:
Hi,
On Thu, 18 Jun 2009, Vincent Untz wrote:
Does this mean there will be another external authorative source for this kind of information in the future (thus, the .spec files will be edited automatically again)? Or can the local file that the .spec
They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
Is there any reason we put the changelog data in %changelog since the data is in .changes files??
No. If you did or do that, you're wasting time. %changelog was and will be rewritten from the content of .changes. We for instance never cared for %changelog sections in .spec files, only for .changes files. Simply leave the section empty (I'm not sure what happens if you leave it out alltogether, so just empty it).
Right. If you leave it out, rpmlint will emit a warning. But I have another question: isn't now a good time to get rid off .changes files completely? (+adjusting tools like vc and osc)
Hum, why? I very much prefer the *.changes files about the changelog in the spec file. Why would you want to change that?
1) They are SUSE specific 2) They contain time with timezone, which sometimes cause trouble
On Fri, Jun 19, Pavol Rusnak wrote:
Wolfgang Rosenauer wrote:
Pavol Rusnak schrieb:
Michael Matz wrote:
Hi,
On Thu, 18 Jun 2009, Vincent Untz wrote:
> Does this mean there will be another external authorative source for > this kind of information in the future (thus, the .spec files will > be edited automatically again)? Or can the local file that the > .spec They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
Is there any reason we put the changelog data in %changelog since the data is in .changes files??
No. If you did or do that, you're wasting time. %changelog was and will be rewritten from the content of .changes. We for instance never cared for %changelog sections in .spec files, only for .changes files. Simply leave the section empty (I'm not sure what happens if you leave it out alltogether, so just empty it).
Right. If you leave it out, rpmlint will emit a warning. But I have another question: isn't now a good time to get rid off .changes files completely? (+adjusting tools like vc and osc)
Hum, why? I very much prefer the *.changes files about the changelog in the spec file. Why would you want to change that?
- They are SUSE specific
- They contain time with timezone, which sometimes cause trouble
Only if you enter them in the wrong order. Especially the time with timezone information is very helpful for me track who made which changes at which time in which order.
Thorsten
Thorsten Kukuk wrote:
On Fri, Jun 19, Pavol Rusnak wrote:
Wolfgang Rosenauer wrote:
Pavol Rusnak schrieb:
Michael Matz wrote:
Hi,
On Thu, 18 Jun 2009, Vincent Untz wrote:
>> Does this mean there will be another external authorative source for >> this kind of information in the future (thus, the .spec files will >> be edited automatically again)? Or can the local file that the >> .spec > They will be formatted - to add the changelog for example. but the > attributes and the texts do not have another source from what I > understood. Is there any reason we put the changelog data in %changelog since the data is in .changes files??
No. If you did or do that, you're wasting time. %changelog was and will be rewritten from the content of .changes. We for instance never cared for %changelog sections in .spec files, only for .changes files. Simply leave the section empty (I'm not sure what happens if you leave it out alltogether, so just empty it).
Right. If you leave it out, rpmlint will emit a warning. But I have another question: isn't now a good time to get rid off .changes files completely? (+adjusting tools like vc and osc)
Hum, why? I very much prefer the *.changes files about the changelog in the spec file. Why would you want to change that?
- They are SUSE specific
- They contain time with timezone, which sometimes cause trouble
Only if you enter them in the wrong order. Especially the time with timezone information is very helpful for me track who made which changes at which time in which order.
Entering changes in wrong order is very easy in OBS. Suppose you have 2 submit-requests against the same version. They both contain patch to .changes file with the same context. When you accept them in the wrong order (even the higher SR number can contain the older change) you're in trouble. Thus I would at least prefer normalizing the times to UTC.
Pavol Rusnak wrote:
[.changes file] Thus I would at least prefer normalizing the times to UTC.
I've just recently changed buildvc in svn to use UTC (actually Michal requested that some time ago already but I forgot about it).
cu Ludwig
Ludwig Nussel wrote:
Pavol Rusnak wrote:
[.changes file] Thus I would at least prefer normalizing the times to UTC.
I've just recently changed buildvc in svn to use UTC (actually Michal requested that some time ago already but I forgot about it).
Thanks Ludwig! I can live with that ... If there are no other objections against using .changes we can close this discussion.
cu Ludwig
On 2009-06-19 14:18:59 +0200, Pavol Rusnak wrote:
- They are SUSE specific
- They contain time with timezone, which sometimes cause trouble
rpm doesnt track hours/minutes.
darix
On 6/19/2009 at 14:00, Pavol Rusnak prusnak@suse.cz wrote:
Right. If you leave it out, rpmlint will emit a warning. But I have another question: isn't now a good time to get rid off .changes files completely? (+adjusting tools like vc and osc)
I actually got kinda used to 'osc vc" to write the changelog and it 'feels' more structured, organized than inside the spec file for me.
Maybe it's only the header lines that make it more structured, but it surely helps.
Dominique
Le vendredi 19 juin 2009, à 05:46 +0200, Michael Matz a écrit :
Hi,
On Thu, 18 Jun 2009, Vincent Untz wrote:
Does this mean there will be another external authorative source for this kind of information in the future (thus, the .spec files will be edited automatically again)? Or can the local file that the .spec
They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
Is there any reason we put the changelog data in %changelog since the data is in .changes files??
No. If you did or do that, you're wasting time. %changelog was and will be rewritten from the content of .changes. We for instance never cared for %changelog sections in .spec files, only for .changes files. Simply leave the section empty (I'm not sure what happens if you leave it out alltogether, so just empty it).
(sorry if this wasn't clear, I meant: the build service always adds the data from .changes to %changelog and commits it; I hate that, I want to keep an empty %changelog since .changes is better structured, more readable, etc.)
Vincent
On 2009-06-19 15:48:24 +0200, Vincent Untz wrote:
Le vendredi 19 juin 2009, à 05:46 +0200, Michael Matz a écrit :
Hi,
On Thu, 18 Jun 2009, Vincent Untz wrote:
Does this mean there will be another external authorative source for this kind of information in the future (thus, the .spec files will be edited automatically again)? Or can the local file that the .spec
They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
Is there any reason we put the changelog data in %changelog since the data is in .changes files??
No. If you did or do that, you're wasting time. %changelog was and will be rewritten from the content of .changes. We for instance never cared for %changelog sections in .spec files, only for .changes files. Simply leave the section empty (I'm not sure what happens if you leave it out alltogether, so just empty it).
(sorry if this wasn't clear, I meant: the build service always adds the data from .changes to %changelog and commits it; I hate that, I want to keep an empty %changelog since .changes is better structured, more readable, etc.)
thats not the obs. those are the autobuild scripts.
darix
On Jun 19, 09 17:00:05 +0200, Marcus Rueckert wrote:
On 2009-06-19 15:48:24 +0200, Vincent Untz wrote:
Le vendredi 19 juin 2009, à 05:46 +0200, Michael Matz a écrit :
Hi,
On Thu, 18 Jun 2009, Vincent Untz wrote:
Does this mean there will be another external authorative source for this kind of information in the future (thus, the .spec files will be edited automatically again)? Or can the local file that the .spec
They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
Is there any reason we put the changelog data in %changelog since the data is in .changes files??
No. If you did or do that, you're wasting time. %changelog was and will be rewritten from the content of .changes. We for instance never cared for %changelog sections in .spec files, only for .changes files. Simply leave the section empty (I'm not sure what happens if you leave it out alltogether, so just empty it).
(sorry if this wasn't clear, I meant: the build service always adds the data from .changes to %changelog and commits it; I hate that, I want to keep an empty %changelog since .changes is better structured, more readable, etc.)
I think you could add somethign like %changelog (nothing)
and then that section does not get updated - not sure if that's the correct syntax, though. Darix?
thats not the obs. those are the autobuild scripts.
Doesn't matter who does it - it simply blows up the spec-file, and wastes space in the packages :)
darix
Stefan
At Fri, 19 Jun 2009 17:07:29 +0200, Stefan Behlert wrote:
On Jun 19, 09 17:00:05 +0200, Marcus Rueckert wrote:
On 2009-06-19 15:48:24 +0200, Vincent Untz wrote:
Le vendredi 19 juin 2009, à 05:46 +0200, Michael Matz a écrit :
Hi,
On Thu, 18 Jun 2009, Vincent Untz wrote:
> Does this mean there will be another external authorative source for > this kind of information in the future (thus, the .spec files will > be edited automatically again)? Or can the local file that the > .spec They will be formatted - to add the changelog for example. but the attributes and the texts do not have another source from what I understood.
Is there any reason we put the changelog data in %changelog since the data is in .changes files??
No. If you did or do that, you're wasting time. %changelog was and will be rewritten from the content of .changes. We for instance never cared for %changelog sections in .spec files, only for .changes files. Simply leave the section empty (I'm not sure what happens if you leave it out alltogether, so just empty it).
(sorry if this wasn't clear, I meant: the build service always adds the data from .changes to %changelog and commits it; I hate that, I want to keep an empty %changelog since .changes is better structured, more readable, etc.)
I think you could add somethign like %changelog (nothing)
and then that section does not get updated - not sure if that's the correct syntax, though. Darix?
thats not the obs. those are the autobuild scripts.
Doesn't matter who does it - it simply blows up the spec-file, and wastes space in the packages :)
Worse than that, there is another possible point of merge conflicts at automatic updates.
Takashi
Stefan Behlert schrieb:
(sorry if this wasn't clear, I meant: the build service always adds the data from .changes to %changelog and commits it; I hate that, I want to keep an empty %changelog since .changes is better structured, more readable, etc.)
I think you could add somethign like %changelog (nothing)
and then that section does not get updated - not sure if that's the correct syntax, though. Darix?
thats not the obs. those are the autobuild scripts.
Doesn't matter who does it - it simply blows up the spec-file, and wastes space in the packages :)
Not sure what you all want so just to make that clear from my pov: I like the *.changes file (and times being UTC as discussed is fine) and I don't like the changes to be propagated into the saved specfile. What we absolutely need though is to have it in the package while building to have the changelog information in the rpm metadata.
Wolfgang
On Thursday 18 June 2009 23:07:04 Vincent Untz wrote:
Is there any reason we put the changelog data in %changelog since the data is in .changes files?? Can't we just let it happen during the build and not have this in the spec files in the obs? This would make them much shorter, which would be a good thing, I think.
No idea. I guess the checkin script would need to be adopted to empty it. Especially as O:F is different to every other project atm in that accepting a package will rewrite the spec file :)
Greetings, Stephan
Le vendredi 19 juin 2009, à 12:15 +0200, Stephan Kulow a écrit :
On Thursday 18 June 2009 23:07:04 Vincent Untz wrote:
Is there any reason we put the changelog data in %changelog since the data is in .changes files?? Can't we just let it happen during the build and not have this in the spec files in the obs? This would make them much shorter, which would be a good thing, I think.
No idea. I guess the checkin script would need to be adopted to empty it.
Where can I find the script? (ie, yes, I'm volunteering for the task)
Vincent
Am Freitag 19 Juni 2009 schrieb Vincent Untz:
Le vendredi 19 juin 2009, à 12:15 +0200, Stephan Kulow a écrit :
On Thursday 18 June 2009 23:07:04 Vincent Untz wrote:
Is there any reason we put the changelog data in %changelog since the data is in .changes files?? Can't we just let it happen during the build and not have this in the spec files in the obs? This would make them much shorter, which would be a good thing, I think.
No idea. I guess the checkin script would need to be adopted to empty it.
Where can I find the script? (ie, yes, I'm volunteering for the task)
Add an option --minchangelog to /work/src/bin/tools/prepare_spec and we'll make sure it will be called that way at checking to factory.
I would suggest the following format
%changelog * Mon Jun 22 2009 coolo@novell.com - see gnome-libs.changes
either take $TODAY or the top of .changes.
Greetings, Stephan
On 2009-06-22 12:42:28 +0200, Stephan Kulow wrote:
Am Freitag 19 Juni 2009 schrieb Vincent Untz:
Le vendredi 19 juin 2009, à 12:15 +0200, Stephan Kulow a écrit :
On Thursday 18 June 2009 23:07:04 Vincent Untz wrote:
Is there any reason we put the changelog data in %changelog since the data is in .changes files?? Can't we just let it happen during the build and not have this in the spec files in the obs? This would make them much shorter, which would be a good thing, I think.
No idea. I guess the checkin script would need to be adopted to empty it.
Where can I find the script? (ie, yes, I'm volunteering for the task)
Add an option --minchangelog to /work/src/bin/tools/prepare_spec and we'll make sure it will be called that way at checking to factory.
I would suggest the following format
%changelog
- Mon Jun 22 2009 coolo@novell.com
- see gnome-libs.changes
either take $TODAY or the top of .changes.
rudi already agreed on leaving an empty %changelog. the code is already in prepare_spec but was commented out for the friday night checkin.
darix
Am Montag 22 Juni 2009 schrieb Marcus Rueckert:
On 2009-06-22 12:42:28 +0200, Stephan Kulow wrote:
Am Freitag 19 Juni 2009 schrieb Vincent Untz:
Le vendredi 19 juin 2009, à 12:15 +0200, Stephan Kulow a écrit :
On Thursday 18 June 2009 23:07:04 Vincent Untz wrote:
Is there any reason we put the changelog data in %changelog since the data is in .changes files?? Can't we just let it happen during the build and not have this in the spec files in the obs? This would make them much shorter, which would be a good thing, I think.
No idea. I guess the checkin script would need to be adopted to empty it.
Where can I find the script? (ie, yes, I'm volunteering for the task)
Add an option --minchangelog to /work/src/bin/tools/prepare_spec and we'll make sure it will be called that way at checking to factory.
I would suggest the following format
%changelog
- Mon Jun 22 2009 coolo@novell.com
- see gnome-libs.changes
either take $TODAY or the top of .changes.
rudi already agreed on leaving an empty %changelog. the code is already in prepare_spec but was commented out for the friday night checkin.
Then let's go ahead with future checkins.
Greetings, Stephan
Le jeudi 18 juin 2009, à 13:51 +0200, Stephan Kulow a écrit :
For 1) I did some scripting to find out where the differences are if I would sr all packages _NOW_ (while pdb is still active). The list of changes is impressive, but I will filter out less important cases (e.g. where only the changelog is affected - as this will still be reformated in the future): http://www.suse.de/%7Ecoolo/spec_patches/ We may end up checkin in these diffs without spamming opensuse-commit, just so you know if your branched package broke (IMO it's very unlikely it will as this affects mostly packages without active development).
Just wondering: I'm considering removing the "Authors" part of all descriptions (sometimes it's very long, and it's really not up-to-date anyway). Is this something that could be done in a similar fashion?
Vincent
Am Donnerstag 18 Juni 2009 schrieb Vincent Untz:
Le jeudi 18 juin 2009, à 13:51 +0200, Stephan Kulow a écrit :
For 1) I did some scripting to find out where the differences are if I would sr all packages _NOW_ (while pdb is still active). The list of changes is impressive, but I will filter out less important cases (e.g. where only the changelog is affected - as this will still be reformated in the future): http://www.suse.de/%7Ecoolo/spec_patches/ We may end up checkin in these diffs without spamming opensuse-commit, just so you know if your branched package broke (IMO it's very unlikely it will as this affects mostly packages without active development).
Just wondering: I'm considering removing the "Authors" part of all descriptions (sometimes it's very long, and it's really not up-to-date anyway). Is this something that could be done in a similar fashion?
No, we don't touch the %descriptions at all anymore. I would suggest we offer a script that does what you suggest to the topic groups for them to run. I wouldn't make it a policy.
Greetings, Stephan
-
Dominique Leuenberger -
Ludwig Nussel -
Marcus Rueckert -
Michael Matz -
Pavol Rusnak -
Petr Baudis -
Richard Guenther -
Stefan Behlert -
Stephan Kulow -
Suman Manjunath -
Takashi Iwai -
Thorsten Kukuk -
Vincent Untz -
Wolfgang Rosenauer