Hi there. I want to see an enhancement to emerge --changelog functionality and I have a patch (see below) to add it. what I'm suggesting is to add feature "bugzilla_links" which will print bugzilla links when doing "emerge --changelog ...". This will shorten time to find out what was fixed in new package version. Example output: ---cut here--- *python-2.4.3-r3 28 Aug 2006; Alastair Tse <liquidx@gentoo.org> +python-2.4.3-r3.ebuild: fix mistake introduced in 2.4.3-r2 where system zlib was used that caused problems on certain machines (#145242) Bugzilla links: http://bugs.gentoo.org/show_bug.cgi?id=145242 *python-2.4.3-r2 26 Aug 2006; Alastair Tse <liquidx@gentoo.org> +python-2.4.3-r2.ebuild: cleanup 2.4.3 ebuild, fix collisions with slotted versions of pydoc and idle, fix multilib installs so that everything is installed in /usr/lib64 rather than just the .so (#118805) 22 Aug 2006; Alastair Tse <liquidx@gentoo.org> python-2.2.3-r6.ebuild, python-2.3.5-r2.ebuild, -python-2.4.2.ebuild, -python-2.4.2-r1.ebuild, -python-2.4.2-r2.ebuild, -python-2.4.3.ebuild, python-2.4.3-r1.ebuild: renamed patches to have short names and version numbers to indicate when they were introduced. patches tarballs are now generated from gentoo-svn. cleaned up older unstable versions of python leaving the latest version for each major release. fixed some installed file collisions between the two version. 20 Jul 2006; Simon Stelling <blubb@gentoo.org> python-2.4.3-r1.ebuild: stable on amd64 11 Jul 2006; Alastair Tse <liquidx@gentoo.org> python-2.4.3-r1.ebuild: python-2.2.3-r6.ebuild, python-2.3.5-r2.ebuild, python-2.4.2.ebuild, python-2.4.2-r1.ebuild, python-2.4.2-r2.ebuild, python-2.4.3.ebuild, python-2.4.3-r1.ebuild: Typo fix in DESCRIPTION (#139463) 09 Jul 2006; Joshua Kinard <kumba@gentoo.org> python-2.4.3-r1.ebuild: Marked stable on mips. 08 Jul 2006; Doug Goldstein <cardoe@gentoo.org> python-2.1.3-r1.ebuild, python-2.2.3-r6.ebuild, python-2.3.5-r2.ebuild, python-2.4.2.ebuild, python-2.4.2-r1.ebuild, python-2.4.2-r2.ebuild, python-2.4.3.ebuild, python-2.4.3-r1.ebuild: split USE='tcltk' to 'tcl' & 'tk' per bug #17808. Nuked X USE flag since it was only to find tk from tcltk 30 Jun 2006; Joel Martin <kanaka@gentoo.org> python-2.4.3-r1.ebuild: Cross-compile update: bindir-libdir patch is no longer needed and will break the patching if it's there. Also, unset CC to force the native python build to use the native compiler. 28 Jun 2006; Tobias Scherbaum <dertobi123@gentoo.org> python-2.4.3-r1.ebuild: ppc stable, #138268 28 Jun 2006; Gustavo Zacarias <gustavoz@gentoo.org> python-2.4.3-r1.ebuild: Stable on sparc wrt #138268 28 Jun 2006; Guy Martin <gmsoft@gentoo.org> python-2.4.3-r1.ebuild: Stable on hppa. 28 Jun 2006; Markus Rothe <corsair@gentoo.org> python-2.4.3-r1.ebuild: Stable on ppc64; bug #138268 27 Jun 2006; Bryan
Hi there. I want to see an enhancement to emerge --changelog functionality and I have a patch (see below) to add it. what I'm suggesting is to add feature "bugzilla_links" which will print bugzilla links when doing "emerge --changelog ...". This will shorten time to find out what was fixed in new package version. Example output: ---cut here--- *python-2.4.3-r3 28 Aug 2006; Alastair Tse <liquidx@gentoo.org> +python-2.4.3-r3.ebuild: fix mistake introduced in 2.4.3-r2 where system zlib was used that caused problems on certain machines (#145242) Bugzilla links: http://bugs.gentoo.org/show_bug.cgi?id=145242 *python-2.4.3-r2 26 Aug 2006; Alastair Tse <liquidx@gentoo.org> +python-2.4.3-r2.ebuild: cleanup 2.4.3 ebuild, fix collisions with slotted versions of pydoc and idle, fix multilib installs so that everything is installed in /usr/lib64 rather than just the .so (#118805) 22 Aug 2006; Alastair Tse <liquidx@gentoo.org> python-2.2.3-r6.ebuild, python-2.3.5-r2.ebuild, -python-2.4.2.ebuild, -python-2.4.2-r1.ebuild, -python-2.4.2-r2.ebuild, -python-2.4.3.ebuild, python-2.4.3-r1.ebuild: renamed patches to have short names and version numbers to indicate when they were introduced. patches tarballs are now generated from gentoo-svn. cleaned up older unstable versions of python leaving the latest version for each major release. fixed some installed file collisions between the two version. 20 Jul 2006; Simon Stelling <blubb@gentoo.org> python-2.4.3-r1.ebuild: stable on amd64 11 Jul 2006; Alastair Tse <liquidx@gentoo.org> python-2.4.3-r1.ebuild: python-2.2.3-r6.ebuild, python-2.3.5-r2.ebuild, python-2.4.2.ebuild, python-2.4.2-r1.ebuild, python-2.4.2-r2.ebuild, python-2.4.3.ebuild, python-2.4.3-r1.ebuild: Typo fix in DESCRIPTION (#139463) 09 Jul 2006; Joshua Kinard <kumba@gentoo.org> python-2.4.3-r1.ebuild: Marked stable on mips. 08 Jul 2006; Doug Goldstein <cardoe@gentoo.org> python-2.1.3-r1.ebuild, python-2.2.3-r6.ebuild, python-2.3.5-r2.ebuild, python-2.4.2.ebuild, python-2.4.2-r1.ebuild, python-2.4.2-r2.ebuild, python-2.4.3.ebuild, python-2.4.3-r1.ebuild: split USE='tcltk' to 'tcl' & 'tk' per bug #17808. Nuked X USE flag since it was only to find tk from tcltk 30 Jun 2006; Joel Martin <kanaka@gentoo.org> python-2.4.3-r1.ebuild: Cross-compile update: bindir-libdir patch is no longer needed and will break the patching if it's there. Also, unset CC to force the native python build to use the native compiler. 28 Jun 2006; Tobias Scherbaum <dertobi123@gentoo.org> python-2.4.3-r1.ebuild: ppc stable, #138268 28 Jun 2006; Gustavo Zacarias <gustavoz@gentoo.org> python-2.4.3-r1.ebuild: Stable on sparc wrt #138268 28 Jun 2006; Guy Martin <gmsoft@gentoo.org> python-2.4.3-r1.ebuild: Stable on hppa. 28 Jun 2006; Markus Rothe <corsair@gentoo.org> python-2.4.3-r1.ebuild: Stable on ppc64; bug #138268 27 Jun 2006; Bryan Østergaard <kloeri@gentoo.org> python-2.4.3-r1.ebuild: Stable on alpha, ia64 and x86. Bugzilla links: http://bugs.gentoo.org/show_bug.cgi?id=118805 http://bugs.gentoo.org/show_bug.cgi?id=139463 http://bugs.gentoo.org/show_bug.cgi?id=17808 http://bugs.gentoo.org/show_bug.cgi?id=138268 http://bugs.gentoo.org/show_bug.cgi?id=138268 http://bugs.gentoo.org/show_bug.cgi?id=138268 ---cut here--- Below is the patch to /usr/lib/portage/bin/emerge ( for sys-apps/portage-2.1.1 ) I'm not a neither python guru nor very familiar with portage internals, though this works fine for me. You might want to change it to conform some portage development conventions. Also I'm not sure where default values should go to avoid empty url if BUGZILLA_URL will not be set. here is the patch itself: --- emerge 2006-09-09 02:19:32.000000000 +0300 +++ emerge.modified 2006-09-09 04:23:45.000000000 +0300 @@ -1723,6 +1723,20 @@ for revision,text in changelogs: print bold('*'+revision) sys.stdout.write(text) + if "bugzilla_links" in self.settings.features: + links_text = self.extract_bugzilla_links(text) + if links_text!="": + print green("\tBugzilla links:") + sys.stdout.write(links_text) + print + + def extract_bugzilla_links(self,text): + p = re.compile("#([0-9]+)") + buglist = p.findall(text) + result = "" + for bug in buglist: + result += "\t "+self.settings["BUGZILLA_URL"]+bug+"\n" + return result def calc_changelog(self,ebuildpath,current,next): current = '-'.join(portage.catpkgsplit(current)[1:])
Is it really *that* hard to copy the bug number, type 'bugs.gentoo.org/' into your browser address bar, and then paste the bug number? :P
its not that hard, though it requires lots of actions: 1. look for bug numbers inside the solid text (or may be just grep output) 2. type url 3. copy bug number 4. hit enter I'm just a bit lazy to do all that stuff. with this feature you just have to copy some urls which are gathered in one place or even much simpler with gnome-terminal just use "open link" from the right-click menu (hence you don't even need to open web-browser). note that this is minor additional feature and could be ignored if not needed.
I'd prefer to keep --changelog as simple as possible. While the proposed enhancement may be quite useful for some, I'm not sure how popular it would be in general.
(In reply to comment #3) > I'd prefer to keep --changelog as simple as possible. While the proposed > enhancement may be quite useful for some, I'm not sure how popular it would be > in general. > that's why I propose to add it as a switchable feature and it should be turned off by default. there are plenty of things in FEATURES which aren't for everyone.
(In reply to comment #5) > (In reply to comment #3) > > I'd prefer to keep --changelog as simple as possible. While the proposed > > enhancement may be quite useful for some, I'm not sure how popular it would be > > in general. > > > > that's why I propose to add it as a switchable feature and it should be turned > off by default. > there are plenty of things in FEATURES which aren't for everyone. I see the following issues: - we should avoid FEATURES bloat (just increases complexity), so this is an always-on or nothing thing IMO, or is there a particular reason why someone would want to disable this if it's implemented? - is there a point in having the BUGZILLA_URL variable? What realistic use cases are there for users setting this variable? - is the #\d+ pattern exact enough to not produce significant numbers of false positive or false negative matches? Is it documented anywhere that people should use that pattern? - should this really be a separate section, or an inline replacement? Could see arguments for both.
I just wanted to propose exactly this feature, so I'd like to strengthen this: One more click might not sound that much, but when you're interested in the changes in some package and read it on every update, the many small (and needless) actions amount for quite much lost time, which might have been spent far better on something else besides firing up my browser with bugs.gentoo.org and entering the bug number. And about people who might want to disable this: Those people who prefer more concise output to having clickable links (and maybe scripts which are intended to just put out the exact changelog, not a modified changelog). What would be really bad in applying this patch?
(In reply to comment #7) > What would be really bad in applying this patch? Until you tell me how will this is exactly supposed to distinguish between '$foo bug #123456' where $foo can stand for any upstream issue tracker out there and a 'genuine' Gentoo bug, this should be closed as CANTFIX because it's going to produce nonsense in tons of cases. Also note you can use terminal features to get the same behavior you are suggesting here already, definitely with rxvt-unicode and quite likely quite with a couple of others. IOW, this doesn't belong to portage.
(In reply to comment #8) > (In reply to comment #7) > > What would be really bad in applying this patch? > > Until you tell me how will this is exactly supposed to distinguish between > '$foo bug #123456' where $foo can stand for any upstream issue tracker out > there and a 'genuine' Gentoo bug, this should be closed as CANTFIX because it's > going to produce nonsense in tons of cases. May be I'm wrong, but I hadn't see any #123456-like mentions of upstream bugs in changelogs. Anyway having "bug #123456" from another issue tracker is quite senseless in ebuild changelogs. Not that I didn't wish to see some information about upstream bugfixes sometimes instead of just "version bump", but I understand why the upstream bugs aren't there at all. Changelog entry should always reflect gentoo-related information. For example version bump is absolutely gentoo thing - it marks arrival of the new ebuild, not the actual upstream release. Ans also seeing #123456 from another tracker will be confusing to the human reader too, not only to the parser. > Also note you can use terminal features to get the same behavior you are > suggesting here already, definitely with rxvt-unicode and quite likely quite > with a couple of others. IOW, this doesn't belong to portage. I don't think this is a valid argument. ok, lets throw away colorization, formatting and just output a raw information stream anywehere, anyone could use bash+grep+sed+awk+terminal_features+whatever to extract whaterver he wants. Anyway if you don't see a point in this enhancement, then ok. Just close it. It's not that I'm going to fight for a minor enhancement for conveinience.
(In reply to comment #9) > Anyway having "bug #123456" from another issue tracker is quite senseless in > ebuild changelogs. > Changelog entry should always reflect gentoo-related information. Pardon, how's referring to upstream issue trackers senseless? So, upstream fixing a bug and us referring to that bug in CL for a new revision is not Gentoo-related just because we don't have any Gentoo bug about that??? Anyway, as already noted in Comment #6, Comment #8 etc. - with no standardized syntax for this, this is going to produce false positives, false negatives and misleading information.
(In reply to comment #10) > (In reply to comment #9) > > Anyway having "bug #123456" from another issue tracker is quite senseless in > > ebuild changelogs. > > Changelog entry should always reflect gentoo-related information. > > Pardon, how's referring to upstream issue trackers senseless? So, upstream > fixing a bug and us referring to that bug in CL for a new revision is not > Gentoo-related just because we don't have any Gentoo bug about that??? > > Anyway, as already noted in Comment #6, Comment #8 etc. - with no standardized > syntax for this, this is going to produce false positives, false negatives and > misleading information. > Actually that upstream bugfix will go to some X.Y.Z+1 release by the upstream, and then it will be noted in gentoo changelog as "version bump". Personally I've never saw changelog entries like "version bump, fixes upstream bug #smth". I agree that the theoretical possibility of false positives exists, so may be some policy for changelog entries writing is needed to avoid this possibility. Anyway changelog entry is not the place to give a reference to foreign issue tracker. If it is link then ofcourse this will not affect suggested functionality, if it is the bug number (similar to references to gentoo bugzilla) then common reader of changelog should magically know what is the url of the issue tracker for the package upstream, which is not good as for me. And actually this will need writing "no-no don't look at gentoo bugzilla, its the bug somewhere else". This will be confusing human reader in any case.
(In reply to comment #11) > Anyway changelog entry is not the place to give a reference to foreign issue > tracker. This is plain nonsense, please don't dictate us what issue trackers we may refer to in changelogs.
(In reply to comment #12) > (In reply to comment #11) > > Anyway changelog entry is not the place to give a reference to foreign issue > > tracker. > > This is plain nonsense, please don't dictate us what issue trackers we may > refer to in changelogs. > Should I put lot of IMHOs there? I'm definitely don't want to dictate anyone, just some thoughts about the convenience for the changelog reader. Ok, as I've already said, if I didn't succeed in convincing that feature is worth including, just close the bug with WONTFIX, it will serve better as +1 in closed bug statistics, then as basement of pointless arguing.
The feature sounds awesome. My usual workflow is to run `emerge --changelog` on interesting updates, copy the bug numbers and paste them into my browser. This would simplify the task for me.
app-portage/porthole has had (for years) a highlighted changelog display along with making the bug numbers listed in it dbl-clickable to open the bug in your browser. Guis are better at some things ;) While it might be a nice feature to have, it is very low in the priorities. There are far more important things to do in the portage code base.
I guess this is obsolete now that --changelog is gone.
