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 %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?
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?
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 _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?
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?
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?
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?
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 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?
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?
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?
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. 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?
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 other security fixes. -- Chris Adams cmad...@hiwaay.net 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?
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?
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?
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?
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?
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?
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?
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?
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 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?
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 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 old NVR? - Which changes are relevant to %changelog users? ... That is, cutting at N 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?
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 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 old 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 N 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?
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: 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 old 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 N 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?
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 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 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?
- 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?
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 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 cmad...@hiwaay.net 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?
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 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?
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?
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?
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?
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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?
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 rdie...@math.unl.edu 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?
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 --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 rdie...@math.unl.edu 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?
在 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
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 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?
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?
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 (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?
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?
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
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 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?
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 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?
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 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?
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?
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 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?
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 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?
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 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?
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 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 cmad...@hiwaay.net 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?
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
