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
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.
On Sat, Apr 20, 2013 at 12:47 AM, Toshio Kuratomi a.bad...@gmail.com 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
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
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
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
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
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
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
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
On Sat, Apr 20, 2013 at 12:25 AM, Richard W.M. Jones
rjo...@redhat.com 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.
Once upon a time, Ralf Corsepius rc040...@freenet.de 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
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
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
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
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
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
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)
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 |
On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
boche...@fedoraproject.org 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
On 04/17/2013 12:03 PM, drago01 wrote:
On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
boche...@fedoraproject.org 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
On Wed, Apr 17, 2013 at 12:11 PM, Ralf Corsepius rc040...@freenet.de wrote:
On 04/17/2013 12:03 PM, drago01 wrote:
On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
boche...@fedoraproject.org wrote:
On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:
For limiting the change log entries
On 04/17/2013 12:19 PM, drago01 wrote:
On Wed, Apr 17, 2013 at 12:11 PM, Ralf Corsepius rc040...@freenet.de wrote:
On 04/17/2013 12:03 PM, drago01 wrote:
On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
boche...@fedoraproject.org wrote:
On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:
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 rc040...@freenet.de
wrote:
On 04/17/2013 12:03 PM, drago01 wrote:
On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
- 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
Once upon a time, drago01 drag...@gmail.com 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
Am 17.04.2013 12:03, schrieb drago01:
On Wed, Apr 17, 2013 at 5:18 AM, Mathieu Bridon
boche...@fedoraproject.org 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
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
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
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
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
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
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
On Tue, Apr 16, 2013 at 9:25 PM, Dan Fruehauf malko...@gmail.com 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
在 2013-4-17 AM9:26，Dan Fruehauf malko...@gmail.com写道：
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
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
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
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 ffe...@redhat.com wrote:
On 04/17/2013 10:25 AM, Dan Fruehauf wrote:
That's around 50K, and compressed
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
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
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
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
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 rdie...@math.unl.edu wrote:
Richard Hughes wrote:
Is there any guidance as when to trim %changelog down
On 15 Apr 2013 14:16, Pierre-Yves Chibon pin...@pingoured.fr 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
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
On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi a.bad...@gmail.comwrote:
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
Dne 15.4.2013 18:03, Richard Shaw napsal(a):
On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi a.bad...@gmail.com
mailto:a.bad...@gmail.com 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
On Mon, 15 Apr 2013 11:03:34 -0500
Richard Shaw hobbes1...@gmail.com wrote:
On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi
a.bad...@gmail.comwrote:
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
Once upon a time, Vít Ondruch vondr...@redhat.com 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
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
50 matches
Mail list logo
