Re: Trimming (or obsoleting) %changelog?

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.

Re: Trimming (or obsoleting) %changelog?

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 %c

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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 o

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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 k

Re: Trimming (or obsoleting) %changelog?

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 %

Re: Trimming (or obsoleting) %changelog?

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 w

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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 fix

Re: Trimming (or obsoleting) %changelog?

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 pro

Re: Trimming (or obsoleting) %changelog?

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 cou

Re: Trimming (or obsoleting) %changelog?

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 j

Re: Trimming (or obsoleting) %changelog?

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 ma

Re: Trimming (or obsoleting) %changelog?

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?

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)

Re: Trimming (or obsoleting) %changelog?

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.

Re: Trimming (or obsoleting) %changelog?

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 cl

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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 >>> in

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

- 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 i

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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 >>>

Re: Trimming (or obsoleting) %changelog?

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. Thi

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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 compr

Re: Trimming (or obsoleting) %changelog?

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 t

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

在 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?

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 bi

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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?

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

Re: Trimming (or obsoleting) %changelog?

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 kin

Re: Trimming (or obsoleting) %changelog?

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 th

Re: Trimming (or obsoleting) %changelog?

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 E

Re: Trimming (or obsoleting) %changelog?

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 len

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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 be

Re: Trimming (or obsoleting) %changelog?

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 whi

Re: Trimming (or obsoleting) %changelog?

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 >

Re: Trimming (or obsoleting) %changelog?

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

Re: Trimming (or obsoleting) %changelog?

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 ch

Trimming (or obsoleting) %changelog?

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