Re: Trimming (or obsoleting) %changelog?

[Kevin Kofler]

Florian Festi wrote:
> That's not correct. The change log is stored within the rpm header which
> is not compressed. While there have been efforts to compress the header
> those changes have not (yet) made it upstream as it would make rpm
> packages completely incompatible with older rpm versions.

Then that's what needs to be fixed. How to deal with the compatibility 
issue? Just phase it in gradually: provide Fedora n and n+1 with RPM support 
for the feature (either by shipping with it from the start or as an update), 
but do not enable it by default, then make the switch for Fedora n+2. We do 
not support direct upgrades from n-1 to n+2 (=(n-1)+3) anyway. For upstream, 
just leave it off by default for the foreseeable future, enable it in 
redhat-rpm-config for Fedora only. I fail to see the issue.

I'm also against trimming changelogs: It loses history and it's arguably a 
violation of the GPL (which requires you to list all the changes you made) 
for GPLed packages. I'd even go as far as saying that all the changelogs 
that were trimmed should be untrimmed (by recovering the missing pieces from 
old copies of the specfile in the SCM history).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Kevin Kofler]

Alex G. wrote:
> I've always seen the %changelog as a relic from times when we didn't
> have reliable source SCMs. For me, it is redundant (and boring) to have
> to update the %changelog, while I have the exact same information in the
> git history.
> 
> I think the best way to go is to obsolete %changelog, and extract the
> changelog directly from git history. I don't care as much about how far
> back it should go. As far as knowing the package version (i.e. 1.2.3-6)
> for each commit, that can easily be handled with a git hook.
> 
> So, why bother putting similar information in two places when there are
> better ways to go?

Because git history cannot be fixed after the fact (to fix typos, add 
missing bug references, etc.) without breaking pulls, and in particular, 
contains many "try this", "no, try that", "oops, fix this" commits which 
don't belong in the RPM changelog.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Adam Williamson]

On 20/04/13 10:41 AM, Alex G. wrote:

On 04/20/2013 10:39 AM, Adam Williamson wrote:

On 19/04/13 09:44 PM, Alex G. wrote:

I respectfully disagree with the assertion that the discussion is
circular.


Sorry, not within this thread - but any discussion vaguely in this area
inevitably winds up with someone suggesting that RPM and git logs get
merged somehow. I've done it myself. It's come up probably a half dozen
times just since I've been reading the list.


My apologies. I did not realize this topic has been tried and beaten in
the past.


Oh, I still think it's a good idea, it just seems to be one of those 
things that comes up, gets batted around a bit, then forgotten about...

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Alex G.]

On 04/20/2013 10:39 AM, Adam Williamson wrote:
> On 19/04/13 09:44 PM, Alex G. wrote:
>> I respectfully disagree with the assertion that the discussion is
>> circular.
> 
> Sorry, not within this thread - but any discussion vaguely in this area
> inevitably winds up with someone suggesting that RPM and git logs get
> merged somehow. I've done it myself. It's come up probably a half dozen
> times just since I've been reading the list.

My apologies. I did not realize this topic has been tried and beaten in
the past.

Alex
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Adam Williamson]

On 19/04/13 09:44 PM, Alex G. wrote:

On 04/19/2013 09:44 PM, Adam Williamson wrote:

On 19/04/13 06:16 PM, Alex G. wrote:

On 04/15/2013 05:30 AM, Richard Hughes wrote:

Is there any guidance as when to trim %changelog down to size? Some
packages have thousands of lines of spec file dating back over 15
years which seem kinda redundant now we're using git.



I've always seen the %changelog as a relic from times when we didn't
have reliable source SCMs. For me, it is redundant (and boring) to have
to update the %changelog, while I have the exact same information in the
git history.

I think the best way to go is to obsolete %changelog, and extract the
changelog directly from git history. I don't care as much about how far
back it should go. As far as knowing the package version (i.e. 1.2.3-6)
for each commit, that can easily be handled with a git hook.

So, why bother putting similar information in two places when there are
better ways to go?


Thanks - I just won a small bet with myself as to when this thread would
circle back to that discussion yet again...


I respectfully disagree with the assertion that the discussion is circular.


Sorry, not within this thread - but any discussion vaguely in this area 
inevitably winds up with someone suggesting that RPM and git logs get 
merged somehow. I've done it myself. It's come up probably a half dozen 
times just since I've been reading the list.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Peter Robinson]

On Sat, Apr 20, 2013 at 12:47 AM, Toshio Kuratomi  wrote:
> On Fri, Apr 19, 2013 at 12:51:05PM -0700, Adam Williamson wrote:
>> On 19/04/13 10:18 AM, Ralf Corsepius wrote:
>>
>> >Last time, we've had this kind of discussions, people were claiming they
>> >were querying changelogs from _binary_ rpms and from installed rpms (rpm
>> >-q --changelog)
>>
>> I do that. All the time. Sometimes going back a long, long time.
>>
>> I could certainly work around the limitation if the binary RPM
>> changelogs were cut off, but it would require me to change, if anyone
>> cares.
>
> Is there a cutoff date that would cover maybe 90% of your use cases?  I
> think that one year would be too short for my use cases as well.  But there
> are packages in the distro with changelogs going back to the RHL/fedora.us
> days and I personally never go back even half that far.  If we chose a date
> two years or three years or even four years in the past, it might be a
> reasonable compromise for everyone.


I think about 18 months is useful, they do take up a surprisingly
large amount of space if you've got a small device like a XO-1.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Alex G.]

On 04/19/2013 09:44 PM, Adam Williamson wrote:
> On 19/04/13 06:16 PM, Alex G. wrote:
>> On 04/15/2013 05:30 AM, Richard Hughes wrote:
>>> Is there any guidance as when to trim %changelog down to size? Some
>>> packages have thousands of lines of spec file dating back over 15
>>> years which seem kinda redundant now we're using git.
>>>
>>
>> I've always seen the %changelog as a relic from times when we didn't
>> have reliable source SCMs. For me, it is redundant (and boring) to have
>> to update the %changelog, while I have the exact same information in the
>> git history.
>>
>> I think the best way to go is to obsolete %changelog, and extract the
>> changelog directly from git history. I don't care as much about how far
>> back it should go. As far as knowing the package version (i.e. 1.2.3-6)
>> for each commit, that can easily be handled with a git hook.
>>
>> So, why bother putting similar information in two places when there are
>> better ways to go?
> 
> Thanks - I just won a small bet with myself as to when this thread would
> circle back to that discussion yet again...

I respectfully disagree with the assertion that the discussion is circular.
I might have been vague when I said "extract". What I meant was to
 - [have 'fedpkg build' automatically] create a changelog from the git
history
 - include that changelog in the rpm headers
 - the changelog is visible with 'rpm -q --changelog'.
Now both %changelog lovers and git lovers are happy campers.

Anyway, I see my argument will be going nowhere pretty soon.

Best wishes,
Alex
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Adam Williamson]

On 19/04/13 06:16 PM, Alex G. wrote:

On 04/15/2013 05:30 AM, Richard Hughes wrote:

Is there any guidance as when to trim %changelog down to size? Some
packages have thousands of lines of spec file dating back over 15
years which seem kinda redundant now we're using git.



I've always seen the %changelog as a relic from times when we didn't
have reliable source SCMs. For me, it is redundant (and boring) to have
to update the %changelog, while I have the exact same information in the
git history.

I think the best way to go is to obsolete %changelog, and extract the
changelog directly from git history. I don't care as much about how far
back it should go. As far as knowing the package version (i.e. 1.2.3-6)
for each commit, that can easily be handled with a git hook.

So, why bother putting similar information in two places when there are
better ways to go?


Thanks - I just won a small bet with myself as to when this thread would 
circle back to that discussion yet again...

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Alex G.]

On 04/15/2013 05:30 AM, Richard Hughes wrote:
> Is there any guidance as when to trim %changelog down to size? Some
> packages have thousands of lines of spec file dating back over 15
> years which seem kinda redundant now we're using git.
> 

I've always seen the %changelog as a relic from times when we didn't
have reliable source SCMs. For me, it is redundant (and boring) to have
to update the %changelog, while I have the exact same information in the
git history.

I think the best way to go is to obsolete %changelog, and extract the
changelog directly from git history. I don't care as much about how far
back it should go. As far as knowing the package version (i.e. 1.2.3-6)
for each commit, that can easily be handled with a git hook.

So, why bother putting similar information in two places when there are
better ways to go?

Alex
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Toshio Kuratomi]

On Fri, Apr 19, 2013 at 12:51:05PM -0700, Adam Williamson wrote:
> On 19/04/13 10:18 AM, Ralf Corsepius wrote:
> 
> >Last time, we've had this kind of discussions, people were claiming they
> >were querying changelogs from _binary_ rpms and from installed rpms (rpm
> >-q --changelog)
> 
> I do that. All the time. Sometimes going back a long, long time.
> 
> I could certainly work around the limitation if the binary RPM
> changelogs were cut off, but it would require me to change, if anyone
> cares.

Is there a cutoff date that would cover maybe 90% of your use cases?  I
think that one year would be too short for my use cases as well.  But there
are packages in the distro with changelogs going back to the RHL/fedora.us
days and I personally never go back even half that far.  If we chose a date
two years or three years or even four years in the past, it might be a
reasonable compromise for everyone.

-Toshio


pgpvzCAe3t65N.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Adam Williamson]

On 19/04/13 10:18 AM, Ralf Corsepius wrote:


Last time, we've had this kind of discussions, people were claiming they
were querying changelogs from _binary_ rpms and from installed rpms (rpm
-q --changelog)


I do that. All the time. Sometimes going back a long, long time.

I could certainly work around the limitation if the binary RPM 
changelogs were cut off, but it would require me to change, if anyone cares.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Chris Adams]

Once upon a time, Ralf Corsepius  said:
> Last time, we've had this kind of discussions, people were claiming they 
> were querying changelogs from _binary_ rpms and from installed rpms (rpm 
> -q --changelog)

_This_ time, I've said I do that, especially when looking for CVE and
other security fixes.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Christopher Meng]

On Sat, Apr 20, 2013 at 12:25 AM, Richard W.M. Jones 
 wrote:

I have just tested this by adding it to a random package that I
maintain, and it appears to work.

The changelog in the RPM I just built is trimmed to 1 year, even
though the spec file contains a much longer changelog.

One possible problem -- maybe it's not -- is that the generated
.src.rpm changelog also gets truncated, but the spec file inside is
intact.



Do we have an option for trimming by releases ? Maybe in the last 1 
year one package just has changelog of Fedora xx Mass Rebuilding...In 
this case, what should we do?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Ralf Corsepius]

On 04/19/2013 06:57 PM, Tom Callaway wrote:

On 04/19/2013 12:25 PM, Richard W.M. Jones wrote:

On Fri, Apr 19, 2013 at 11:17:09AM -0400, Tom Callaway wrote:

On 04/18/2013 11:34 AM, Richard W.M. Jones wrote:

%global _changelog_trimtime %(date +%s -d "1 year ago")


If that actually works, we could make fedpkg set it.


I have just tested this by adding it to a random package that I
maintain, and it appears to work.

The changelog in the RPM I just built is trimmed to 1 year, even
though the spec file contains a much longer changelog.

One possible problem -- maybe it's not -- is that the generated
.src.rpm changelog also gets truncated, but the spec file inside is
intact.


If the spec file is intact, that should be sufficient. I don't think
people are regularly querying changelog info from SRPMs.


Last time, we've had this kind of discussions, people were claiming they 
were querying changelogs from _binary_ rpms and from installed rpms (rpm 
-q --changelog)


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Tom Callaway]

On 04/19/2013 12:25 PM, Richard W.M. Jones wrote:
> On Fri, Apr 19, 2013 at 11:17:09AM -0400, Tom Callaway wrote:
>> On 04/18/2013 11:34 AM, Richard W.M. Jones wrote:
>>> %global _changelog_trimtime %(date +%s -d "1 year ago")
>>
>> If that actually works, we could make fedpkg set it.
> 
> I have just tested this by adding it to a random package that I
> maintain, and it appears to work.
> 
> The changelog in the RPM I just built is trimmed to 1 year, even
> though the spec file contains a much longer changelog.
> 
> One possible problem -- maybe it's not -- is that the generated
> .src.rpm changelog also gets truncated, but the spec file inside is
> intact.

If the spec file is intact, that should be sufficient. I don't think
people are regularly querying changelog info from SRPMs.

~tom

==
Fedora Project
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Richard W.M. Jones]

On Fri, Apr 19, 2013 at 11:17:09AM -0400, Tom Callaway wrote:
> On 04/18/2013 11:34 AM, Richard W.M. Jones wrote:
> > %global _changelog_trimtime %(date +%s -d "1 year ago")
> 
> If that actually works, we could make fedpkg set it.

I have just tested this by adding it to a random package that I
maintain, and it appears to work.

The changelog in the RPM I just built is trimmed to 1 year, even
though the spec file contains a much longer changelog.

One possible problem -- maybe it's not -- is that the generated
.src.rpm changelog also gets truncated, but the spec file inside is
intact.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Tom Callaway]

On 04/18/2013 11:34 AM, Richard W.M. Jones wrote:
> %global _changelog_trimtime %(date +%s -d "1 year ago")

If that actually works, we could make fedpkg set it.

~tom

==
Fedora Project
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Richard W.M. Jones]

On Wed, Apr 17, 2013 at 12:10:20PM +0900, Florian Festi wrote:
> For limiting the change log entries in the binary packages
> %_changelog_trimtime can be used that take a unix time stamp as an
> integer value. This way the whole history is still available in the spec
> file.

IIUC, this (untested) should trim RPM change logs older than 1 year?

%global _changelog_trimtime %(date +%s -d "1 year ago")

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Florian Festi]

On 04/17/2013 07:03 PM, drago01 wrote:
> Why does it have to be date based?
> Why not having a count based cutoff?
> Like last N entries.

There used to be a count based trimming in rpm < 4.0. I guess the
rational behind a date based approach is that this way entries do not
disappear unexpectedly. As I understand it the feature is meant to be
used on a per package basis. This way you can just add new entries
without bothering about the change log trimming and from time to time
(e.g. once a year) adjust the date to something more appropriate.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Nicolas Mailhot]

Le Mer 17 avril 2013 13:41, Pavel Simerda a écrit :
> - Original Message -
>> Jesus Christ
>
> Unnecessary.
>
>> The git repos are not available to ordinary users, nor
>> are they easily accessible!
>
> 1) The command line way (with fedpkg)
>
> sudo yum install @fedora-packager
> fedpkg clone -a coreutils
>
> 2) The command line way (without fedpkg)
>
> sudo yum install git
> git clone git://pkgs.fedoraproject.org/coreutils.git
>
> 3) The web browser way
>
> http://pkgs.fedoraproject.org/cgit/
>
> (or you can go directly to
> http://pkgs.fedoraproject.org/cgit/coreutils.git)

None of which is practical when you are on a restricted network which is
the case pretty much everywhere in corp space except for software
developer enclaves (because software developers are "special", they are
the guys with multiple screens on their desk, and they are anything but
the normal case)

-- 
Nicolas Mailhot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Ville Skyttä]

On 2013-04-17 12:39, Michael Schwendt wrote:

> It should be up the packager(s) to decide when the package and the packaged
> software have changed so much that old cruft in the %changelog could be
> pruned.

Seconded. BTW what I usually do when pruning old entries is move them
into a separate text file which I then ship as %doc in the package.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Reindl Harald]

Am 17.04.2013 12:03, schrieb drago01:
> On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
>  wrote:
>> On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:
>>> For limiting the change log entries in the binary packages
>>> %_changelog_trimtime can be used that take a unix time stamp as an
>>> integer value. This way the whole history is still available in the spec
>>> file.
>>
>> Could redhat-rpm-config set that automatically, for example to the
>> release date of Fedora N-1?
> 
> Why does it have to be date based?
> Why not having a count based cutoff?
> Like last N entries

because if you look at some RPM's where the changelog
is really really well maintained you see it would make
no sense to strip nearly anything automatically

a combination of both makes sense

* strip anything older than X
* BUT leave at least N numbers of entries AND ignore
  auto-massrebuilds in this count



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Chris Adams]

Once upon a time, drago01  said:
> Why does it have to be date based?
> Why not having a count based cutoff?
> Like last N entries.

Neither is definately the correct thing to do.

All changes starting with the most recent upstream release should stay,
as that tells you (or at least should tell you) the difference between
foo-1.2.3 (upstream) and foo-1.2.3-4.fc18 (apparently 4th release for
Fedora 18).

Automated rebuild entries could be be dropped as soon as the next build
is done.

Any CVE references should probably stay until there's a new upstream
release (no matter how old or how many).
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Pavel Simerda]

- Original Message -
> Jesus Christ

Unnecessary.

> The git repos are not available to ordinary users, nor
> are they easily accessible!

1) The command line way (with fedpkg)

sudo yum install @fedora-packager
fedpkg clone -a coreutils

2) The command line way (without fedpkg)

sudo yum install git
git clone git://pkgs.fedoraproject.org/coreutils.git

3) The web browser way

http://pkgs.fedoraproject.org/cgit/

(or you can go directly to http://pkgs.fedoraproject.org/cgit/coreutils.git)

Cheers,

Pavel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Mathieu Bridon]

On Wed, 2013-04-17 at 12:30 +0200, Ralf Corsepius wrote:
> On 04/17/2013 12:19 PM, drago01 wrote:
> > On Wed, Apr 17, 2013 at 12:11 PM, Ralf Corsepius  
> > wrote:
> >> On 04/17/2013 12:03 PM, drago01 wrote:
> >>>
> >>> On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
> >>>  wrote:
> 
>  On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:
> >
> > For limiting the change log entries in the binary packages
> > %_changelog_trimtime can be used that take a unix time stamp as an
> > integer value. This way the whole history is still available in the spec
> > file.
> 
> 
>  Could redhat-rpm-config set that automatically, for example to the
>  release date of Fedora N-1?
> >>>
> >>>
> >>> Why does it have to be date based?
> >>> Why not having a count based cutoff?
> >>> Like last N entries.
> >>
> >> Ask yourself what changelogs are serve for and you'll find the answer.
> >>
> >> It's questions such as:
> >> - When did a change make it into a package?
> >
> > This is available in the git repo.
> 
> Jesus Christ - The git repos are not available to ordinary users,

They are publicly and anonymously available.

However, they are not available offline, whereas "rpm -q --changelog"
is.


-- 
Mathieu

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Ralf Corsepius]

On 04/17/2013 12:19 PM, drago01 wrote:

On Wed, Apr 17, 2013 at 12:11 PM, Ralf Corsepius  wrote:

On 04/17/2013 12:03 PM, drago01 wrote:


On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
 wrote:


On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:


For limiting the change log entries in the binary packages
%_changelog_trimtime can be used that take a unix time stamp as an
integer value. This way the whole history is still available in the spec
file.



Could redhat-rpm-config set that automatically, for example to the
release date of Fedora N-1?



Why does it have to be date based?
Why not having a count based cutoff?
Like last N entries.


Ask yourself what changelogs are serve for and you'll find the answer.

It's questions such as:
- When did a change make it into a package?


This is available in the git repo.


Jesus Christ - The git repos are not available to ordinary users, nor 
are they easily accessible!




- What are the changes since " NVR"?


Same here ... you can view a log from commit to commit to view that
(even diffs).


- Which changes are relevant to %changelog users?
...

That is, cutting at  would cut at points, which are likely cut off off
the information users are interested in.



We are using git.

The packagers are using git - The distro's users aren't.


You have everything there (not only the changelogs
but the old versions of spec file / patches).


That's an urban myth.

Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[drago01]

On Wed, Apr 17, 2013 at 12:11 PM, Ralf Corsepius  wrote:
> On 04/17/2013 12:03 PM, drago01 wrote:
>>
>> On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
>>  wrote:
>>>
>>> On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:

 For limiting the change log entries in the binary packages
 %_changelog_trimtime can be used that take a unix time stamp as an
 integer value. This way the whole history is still available in the spec
 file.
>>>
>>>
>>> Could redhat-rpm-config set that automatically, for example to the
>>> release date of Fedora N-1?
>>
>>
>> Why does it have to be date based?
>> Why not having a count based cutoff?
>> Like last N entries.
>
> Ask yourself what changelogs are serve for and you'll find the answer.
>
> It's questions such as:
> - When did a change make it into a package?

This is available in the git repo.

> - What are the changes since " NVR"?

Same here ... you can view a log from commit to commit to view that
(even diffs).

> - Which changes are relevant to %changelog users?
> ...
>
> That is, cutting at  would cut at points, which are likely cut off off
> the information users are interested in.


We are using git. You have everything there (not only the changelogs
but the old versions of spec file / patches).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Ralf Corsepius]

On 04/17/2013 12:03 PM, drago01 wrote:

On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
 wrote:

On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:

For limiting the change log entries in the binary packages
%_changelog_trimtime can be used that take a unix time stamp as an
integer value. This way the whole history is still available in the spec
file.


Could redhat-rpm-config set that automatically, for example to the
release date of Fedora N-1?


Why does it have to be date based?
Why not having a count based cutoff?
Like last N entries.

Ask yourself what changelogs are serve for and you'll find the answer.

It's questions such as:
- When did a change make it into a package?
- What are the changes since " NVR"?
- Which changes are relevant to %changelog users?
...

That is, cutting at  would cut at points, which are likely cut off 
off the information users are interested in.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[drago01]

On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
 wrote:
> On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:
>> For limiting the change log entries in the binary packages
>> %_changelog_trimtime can be used that take a unix time stamp as an
>> integer value. This way the whole history is still available in the spec
>> file.
>
> Could redhat-rpm-config set that automatically, for example to the
> release date of Fedora N-1?

Why does it have to be date based?
Why not having a count based cutoff?
Like last N entries.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Michael Schwendt]

On Wed, 17 Apr 2013 11:25:17 +1000, Dan Fruehauf wrote:

> I tend to be against trimming. I was just looking at the binutils changelog
> (goes back to 1997):
> $ rpm -q --changelog binutils | wc -c
> 54984
> 
> That's around 50K, and compressed (RPMs are compressed):
> $ rpm -q --changelog binutils | gzip | wc -c
> 15552
> 
> 15K is nothing. Really. I like to see the whole history of a package, it's
> nice and fun.

"Fun"? Maybe. "Nice"? Not always. The amount of irrelevant details can be
problematic and inconvenient when searching in the %changelog. And all you
find is a ten-year-old entry from an era when the package suffered from
the same/similar bug or was packaged very differently. Other entries would
refer to stuff not being available anymore, such as previous sub-packages,
previous builds, patched features that have been dropped years later,
retired bug trackers (e.g. bugzilla.fedora.us and its ticket numbers).

It should be up the packager(s) to decide when the package and the packaged
software have changed so much that old cruft in the %changelog could be
pruned.

-- 
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc6.git2.1.fc19.x86_64
loadavg: 0.06 0.14 0.16
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Florian Festi]

On 04/17/2013 12:18 PM, Mathieu Bridon wrote:
> On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:
>> For limiting the change log entries in the binary packages
>> %_changelog_trimtime can be used that take a unix time stamp as an
>> integer value. This way the whole history is still available in the spec
>> file.
> 
> Could redhat-rpm-config set that automatically, for example to the
> release date of Fedora N-1?

From a technical POV: Yes, very easily.

Figuring out if this really is a good idea and convincing all necessary
Fedora committees is left as an exercise for the reader.

Florian

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Dan Fruehauf]

I stand corrected then, lets have a look at things uncompressed:
glibc - 360K
gcc - 20K
gdb - 148K

Still fail to see the "big deal", sorry.



On Wed, Apr 17, 2013 at 1:10 PM, Florian Festi  wrote:

> On 04/17/2013 10:25 AM, Dan Fruehauf wrote:
> > That's around 50K, and compressed (RPMs are compressed):
> > $ rpm -q --changelog binutils | gzip | wc -c
> > 15552
> >
> > 15K is nothing. Really. I like to see the whole history of a package,
> > it's nice and fun.
>
> That's not correct. The change log is stored within the rpm header which
> is not compressed. While there have been efforts to compress the header
> those changes have not (yet) made it upstream as it would make rpm
> packages completely incompatible with older rpm versions.
>
> For limiting the change log entries in the binary packages
> %_changelog_trimtime can be used that take a unix time stamp as an
> integer value. This way the whole history is still available in the spec
> file.
>
> Florian
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Mathieu Bridon]

On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:
> For limiting the change log entries in the binary packages
> %_changelog_trimtime can be used that take a unix time stamp as an
> integer value. This way the whole history is still available in the spec
> file.

Could redhat-rpm-config set that automatically, for example to the
release date of Fedora N-1?


-- 
Mathieu

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Florian Festi]

On 04/17/2013 10:25 AM, Dan Fruehauf wrote:
> That's around 50K, and compressed (RPMs are compressed):
> $ rpm -q --changelog binutils | gzip | wc -c
> 15552
> 
> 15K is nothing. Really. I like to see the whole history of a package,
> it's nice and fun.

That's not correct. The change log is stored within the rpm header which
is not compressed. While there have been efforts to compress the header
those changes have not (yet) made it upstream as it would make rpm
packages completely incompatible with older rpm versions.

For limiting the change log entries in the binary packages
%_changelog_trimtime can be used that take a unix time stamp as an
integer value. This way the whole history is still available in the spec
file.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Christopher Meng]

在 2013-4-17 AM9:26，"Dan Fruehauf" 写道：
> Just out of curiosity, what packages have huge changelogs?

Another huge one: openssl
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Andy Grimm]

On Tue, Apr 16, 2013 at 9:25 PM, Dan Fruehauf  wrote:

> Hey,
>
> I tend to be against trimming. I was just looking at the binutils
> changelog (goes back to 1997):
> $ rpm -q --changelog binutils | wc -c
> 54984
>
> That's around 50K, and compressed (RPMs are compressed):
> $ rpm -q --changelog binutils | gzip | wc -c
> 15552
>
> 15K is nothing. Really. I like to see the whole history of a package, it's
> nice and fun.
>
> Perhaps other packages has larger changelogs. I guess common sense is what
> we should use, but generally speaking I'd say don't trim, as it doesn't
> really matter and it's cleaner to have a full changelog, rather than a
> story which starts somewhere in the middle.
>
> Just out of curiosity, what packages have huge changelogs?
>

A lot of them are the ones you'd expect -- toolchain-related packages that
have been around forever like gcc, gdb, glibc.  SELinux related packages
have pretty huge changelogs, too.  I think the winner for greatest
changelog growth rate is likely rhc (the OpenShift client): over 350
entries in less than two years.  :-)

Andy


>
> BR
> Dan Fruehauf.
>
>
> On Mon, Apr 15, 2013 at 10:43 PM, Rex Dieter  wrote:
>
>> Richard Hughes wrote:
>>
>> > Is there any guidance as when to trim %changelog down to size? Some
>> > packages have thousands of lines of spec file dating back over 15
>> > years which seem kinda redundant now we're using git.
>>
>> To me, common sense dictates that it's perfectly ok to trim the length of
>> the changelog as long as items that are relevant to the current release
>> are
>> kept intact.  Use your best judgement where that position lies.
>>
>> -- rex
>>
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Dan Fruehauf]

Hey,

I tend to be against trimming. I was just looking at the binutils changelog
(goes back to 1997):
$ rpm -q --changelog binutils | wc -c
54984

That's around 50K, and compressed (RPMs are compressed):
$ rpm -q --changelog binutils | gzip | wc -c
15552

15K is nothing. Really. I like to see the whole history of a package, it's
nice and fun.

Perhaps other packages has larger changelogs. I guess common sense is what
we should use, but generally speaking I'd say don't trim, as it doesn't
really matter and it's cleaner to have a full changelog, rather than a
story which starts somewhere in the middle.

Just out of curiosity, what packages have huge changelogs?

BR
Dan Fruehauf.


On Mon, Apr 15, 2013 at 10:43 PM, Rex Dieter  wrote:

> Richard Hughes wrote:
>
> > Is there any guidance as when to trim %changelog down to size? Some
> > packages have thousands of lines of spec file dating back over 15
> > years which seem kinda redundant now we're using git.
>
> To me, common sense dictates that it's perfectly ok to trim the length of
> the changelog as long as items that are relevant to the current release are
> kept intact.  Use your best judgement where that position lies.
>
> -- rex
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Christopher Meng]

Maybe trimming the changelog can be a option feature of rpmdev?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Matthew Miller]

On Mon, Apr 15, 2013 at 09:00:00AM -0700, Toshio Kuratomi wrote:
> I believe we've had this discussion before but I don't have a link handy.  I
> think that people said they liked historical information to know when a bug,
> feature, or fix might have entered into a package (where people being end
> users, people who are primarily users, not packagers, even packagers who are
> looking at packagest hat they don't own).  However, people did seem to agree
> that there was a cutoff somewhere in the past where they no longer cared.

It's handy to have it on the system going back the last few updates. Beyond
that, I sometimes *do* care going back beyond that, but wouldn't mind the
history archived somewhere (and somewhere more accessible than deep within
the git history). Losing it completely would be a real shame.




-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Tom Callaway]

On 04/15/2013 09:05 AM, Pierre-Yves Chibon wrote:
> On Mon, 2013-04-15 at 07:43 -0500, Rex Dieter wrote:
>> Richard Hughes wrote:
>>
>>> Is there any guidance as when to trim %changelog down to size? Some
>>> packages have thousands of lines of spec file dating back over 15
>>> years which seem kinda redundant now we're using git.
>>
>> To me, common sense dictates that it's perfectly ok to trim the length of 
>> the changelog as long as items that are relevant to the current release are 
>> kept intact.  Use your best judgement where that position lies.
> 
> I wonder if there are legal issues involved as the %changelog also list
> all the person that worked on that spec file.
> As for all project, in case of licensing changes, you need to know all
> the authors that ever contributed to the project.
> But again, IANAL :)

I see no legal issues with trimming a %changelog. We don't use that as a
commit tracking mechanism in any real way. :)

~tom

==
Fedora Project
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Chris Adams]

Once upon a time, Vít Ondruch  said:
> Not sure if the age of entry is the only metrics which should be used. 
> What if there was no change in last 3 years? Then we will have just one 
> changelog entry? Just thinking loud ...

Especially if there was no upstream release in the last 3 years and
there have been security issues (where %changelog entries might be the
only documentation that issues have been fixed).  Certainly no entries
that mention CVEs should be auto-removed if the package version hasn't
changed.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[seth vidal]

On Mon, 15 Apr 2013 11:03:34 -0500
Richard Shaw  wrote:

> On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi
> wrote:
> 
> > If I remember, I tend to trim off changelog entries that are more
> > than two years old once a year for packages that I own.  Two years
> > is twice the length of a Fedora EOL cycle and since it grows to
> > three years during the interim, that seems a reasonable distance in
> > the past for people trying to get a quick glimpse of when something
> > might have changed.
> 
> 
> Would it be difficult to have some part of the build process check to
> see if there's dates older than 2-3 years and report it somewhere?
> Preferably somewhere where it will get noticed, but not be obtrusive.
> 

createrepo truncates the changelogs in the repodata to some limit - I
forget what it is set to in koji.

Istr that something like that was made an option in rpm, too.

-sv
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Vít Ondruch]

Dne 15.4.2013 18:03, Richard Shaw napsal(a):
On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi > wrote:


If I remember, I tend to trim off changelog entries that are more
than two
years old once a year for packages that I own.  Two years is twice the
length of a Fedora EOL cycle and since it grows to three years
during the
interim, that seems a reasonable distance in the past for people
trying to
get a quick glimpse of when something might have changed.


Would it be difficult to have some part of the build process check to 
see if there's dates older than 2-3 years and report it somewhere? 
Preferably somewhere where it will get noticed, but not be obtrusive.


Not sure if the age of entry is the only metrics which should be used. 
What if there was no change in last 3 years? Then we will have just one 
changelog entry? Just thinking loud ...


Vít
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Richard Shaw]

On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi wrote:

> If I remember, I tend to trim off changelog entries that are more than two
> years old once a year for packages that I own.  Two years is twice the
> length of a Fedora EOL cycle and since it grows to three years during the
> interim, that seems a reasonable distance in the past for people trying to
> get a quick glimpse of when something might have changed.


Would it be difficult to have some part of the build process check to see
if there's dates older than 2-3 years and report it somewhere? Preferably
somewhere where it will get noticed, but not be obtrusive.

Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Toshio Kuratomi]

On Mon, Apr 15, 2013 at 11:30:20AM +0100, Richard Hughes wrote:
> Is there any guidance as when to trim %changelog down to size? Some
> packages have thousands of lines of spec file dating back over 15
> years which seem kinda redundant now we're using git.
> 
I believe we've had this discussion before but I don't have a link handy.  I
think that people said they liked historical information to know when a bug,
feature, or fix might have entered into a package (where people being end
users, people who are primarily users, not packagers, even packagers who are
looking at packagest hat they don't own).  However, people did seem to agree
that there was a cutoff somewhere in the past where they no longer cared.

If I remember, I tend to trim off changelog entries that are more than two
years old once a year for packages that I own.  Two years is twice the
length of a Fedora EOL cycle and since it grows to three years during the
interim, that seems a reasonable distance in the past for people trying to
get a quick glimpse of when something might have changed.

-Toshio


pgpjRhllg5b01.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[John5342]

On 15 Apr 2013 14:16, "Pierre-Yves Chibon"  wrote:
>
> On Mon, 2013-04-15 at 07:43 -0500, Rex Dieter wrote:
> > Richard Hughes wrote:
> >
> > > Is there any guidance as when to trim %changelog down to size? Some
> > > packages have thousands of lines of spec file dating back over 15
> > > years which seem kinda redundant now we're using git.
> >
> > To me, common sense dictates that it's perfectly ok to trim the length
of
> > the changelog as long as items that are relevant to the current release
are
> > kept intact.  Use your best judgement where that position lies.
>
> I wonder if there are legal issues involved as the %changelog also list
> all the person that worked on that spec file.
> As for all project, in case of licensing changes, you need to know all
> the authors that ever contributed to the project.
> But again, IANAL :)

I believe the spec files are by default covered under the Fedora
Contributor License Agreement (the cla all contributors have to agree to in
fas before contributing) and that covers any project wide license changes
too I believe.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Richard Hughes]

At the moment, my best judgment is "trim anything older than one year"
and that's what I've been doing to my packages. Thanks for the sanity
check.

Richard

On 15 April 2013 13:43, Rex Dieter  wrote:
> Richard Hughes wrote:
>
>> Is there any guidance as when to trim %changelog down to size? Some
>> packages have thousands of lines of spec file dating back over 15
>> years which seem kinda redundant now we're using git.
>
> To me, common sense dictates that it's perfectly ok to trim the length of
> the changelog as long as items that are relevant to the current release are
> kept intact.  Use your best judgement where that position lies.
>
> -- rex
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Pierre-Yves Chibon]

On Mon, 2013-04-15 at 07:43 -0500, Rex Dieter wrote:
> Richard Hughes wrote:
> 
> > Is there any guidance as when to trim %changelog down to size? Some
> > packages have thousands of lines of spec file dating back over 15
> > years which seem kinda redundant now we're using git.
> 
> To me, common sense dictates that it's perfectly ok to trim the length of 
> the changelog as long as items that are relevant to the current release are 
> kept intact.  Use your best judgement where that position lies.

I wonder if there are legal issues involved as the %changelog also list
all the person that worked on that spec file.
As for all project, in case of licensing changes, you need to know all
the authors that ever contributed to the project.
But again, IANAL :)

Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

[Rex Dieter]

Richard Hughes wrote:

> Is there any guidance as when to trim %changelog down to size? Some
> packages have thousands of lines of spec file dating back over 15
> years which seem kinda redundant now we're using git.

To me, common sense dictates that it's perfectly ok to trim the length of 
the changelog as long as items that are relevant to the current release are 
kept intact.  Use your best judgement where that position lies.

-- rex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Trimming (or obsoleting) %changelog?

[Richard Hughes]

Is there any guidance as when to trim %changelog down to size? Some
packages have thousands of lines of spec file dating back over 15
years which seem kinda redundant now we're using git.

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel