After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 424083 - [PATCH] additional info for the 'About' panel and the User-Agent header line
[PATCH] additional info for the 'About' panel and the User-Agent header line
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
pre-1.0 betas
Other All
: High critical
: ---
Assigned To: Charles Kerr
Pan QA Team
Depends on:
Blocks:
 
 
Reported: 2007-03-29 11:12 UTC by SciFi
Modified: 2011-02-19 18:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to add more info to the 'About' panel and User-Agent header line (2.96 KB, patch)
2007-03-29 11:14 UTC, SciFi
needs-work Details | Review

Description SciFi 2007-03-29 11:12:22 UTC
Hi,

This patch will add more information to the Pan 'About' panel as well as the User-Agent header line when posting (if checkmarked in the More Headers tab).

For my Dual G5 running MacOSX 10.4.9, the 'About' panel now shows:
Demon Sweat (SVNr215; powerpc-apple-darwin8.9.0)

and the User-Agent header line looks like this:
User-Agent: Pan/0.126 (Demon Sweat; SVNr215; powerpc-apple-darwin8.9.0)

These values are brought in automatically during ./configure.

For release tarballs, there normally are no .svn subdirs, so the logic ought to insert the word 'release' instead of the SVNr### for the middle bits.

I don't know if Pan sends any such info when talking to the NNTP or e-mail servers (like during a 'HELO' dialogue).  If so, please let me know where the code is located for this.  ;)

Many servers take 'inventory' of the software being used by scanning the User-Agent line (and possibly the 'HELO' message).  I'm not sure if there is a specific RFC for the User-Agent line past the Pan/0.126 part (that much _is_ documented at <http://www.landfield.com/usenet/usefor/drafts/draft-ietf-usefor-article-03.txt>).  But it seems we can add anything so long as it's in parentheses e.g. '(foo; bar; etc.)', so now we can register our various platforms to be counted as a Pan user.

(I'll put the patch into an attachment soon as bugzilla creates this record.)

Thanks.
Comment 1 SciFi 2007-03-29 11:14:44 UTC
Created attachment 85509 [details] [review]
patch to add more info to the 'About' panel and User-Agent header line
Comment 2 Charles Kerr 2007-04-14 15:26:36 UTC
*Many* users over the years have complained about Pan putting their OS info
in the User-Agent header.

Maybe you could revise the patch such that these bits are only added if the
user calls autogen/autoconf with a particular configure argument?
Comment 3 SciFi 2007-04-17 10:33:26 UTC
(In reply to comment #2 from Charles Kerr)
> *Many* users over the years have complained about Pan putting their OS info
> in the User-Agent header.

I wonder how many of "those people" know that all web-browsers do the same thing with even more details?  ;)

OTOH how many of the complainers actually come from the NNTP server sysadmins?  I hear most sysadmins would love to know what software is being used and on which platforms, then they could recommend good ones or disapprove of badly-acting ones; this then also becomes a helpful debugging tool.  I only wish the parenthetical data could be standardised, and I do know it's too easy to be faked.

> 
> Maybe you could revise the patch such that these bits are only added if the
> user calls autogen/autoconf with a particular configure argument?

I'll give it a shot, not being an expert in those areas.  ;)

What should we name the configure option:
--enable-extra-info
--enable-extra-useragent-data
or should it be a --with- option?

> 

btw I nearly lost track of this bug -- bugzilla filtered out this bug in its 'browse' list since it doesn't include the NEEDINFO status and thus thinks it is not an 'open' one.  oops.  ;)


Thanks for the suggestion, let me take a crack at it...

Comment 4 Christophe Lambin 2008-12-06 13:25:26 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 5 SciFi 2008-12-09 22:09:44 UTC
Hi,

*I* am the one who needs “further information”, see Comment #3 above!
I opened this ticket, and I wrote Comment #3 above asking, in particular I quote:

> What should we name the configure option:
> --enable-extra-info
> --enable-extra-useragent-data
> or should it be a --with- option?

This ticket needs to stay open so someone can see this ticket and respond, please.  Closed as “RESOLVED” tickets are too easily ignored (no matter the reason).

What’s more, “Incomplete” isn’t the correct label to use.  This ticket was in a NEEDINFO condition.  The Bugzilla help page for “Incomplete” mentions: “unlike NEEDINFO, no answer is possible or expected.”  -->  I EXPECT an answer *is* possible, never mind anyone having time to answer it (I am patient).

BTW normal Bugzilla searches still filters–out NEEDINFO status, treating it as a non-opened status.  I missed this ticket again during a search, esp now that it is marked “Resolved”!  (How many other tickets are in this condition now, which we are missing during a normal search???)

I know the idea in this ticket needs work.  I want it to be a make–time feature rather than an autoconf macro (that presently only kicks-in properly when ./configure is run).  But my question in Comment #3 still applies, I don’t know where to take this next until it’s answered, please.  Closing it means it’s been answered, that’s not the right thing to do.

As a bonus, I’m also trying to figure out an easy way to keep track of custom patches, for ex. ones that are applied from other tickets here.  Right now it’s a manual hand-hack to config.h to show ticket-numbers after the Release/SVNr### string e.g.
“SVNr364+549655+403797+541676+424083”
meaning: on top of SVNr364, we’ve applied the patches found in those tickets.
None of the Repo systems (CVS, SVN, Git, etc. etc. etc. etc. etc.) and no patch tools AFAIK have an easy way to keep track of this kind of thing.

This ticket system needs better labelling & search facilities.  I say do not mark something “Resolved” UNTIL IT REALLY *IS*.  Find a better label for the time being on such tickets.  Work within the system that we have here, stop causing these kinds of tickets to become hidden during normal searches, please.  NEEDINFO still hides these during a normal search, but at least we know how to invoke a search for them, and is the truthful label for such tickets.

Thanks.

Comment 6 SciFi 2008-12-09 22:16:06 UTC
~sigh~

When I try to change status to NEEDINFO, Bugzilla showed me a red box:
>>>>
Not allowed
You tried to change the Status field from UNCONFIRMED to NEEDINFO , but only a sufficiently empowered user may change that field.
<<<<

…and me being the creator/author of this ticket…

…no wonder why some volunteers give up on trying to help with projects…

Comment 7 Kenneth Haley 2010-03-26 04:32:07 UTC
I've put an updated version in my repo.  It adds a user-agent-extra-info flag in preferences.xml to control the addition of the info to the header.
Comment 8 Petr Kovar 2011-01-25 00:55:30 UTC
Ad commit abe75ce7cddf4c4afe44 (https://github.com/lostcoder/pan2/commit/abe75ce7cddf4c4afe44846a2eba215e39f487a6):

This needs git-archive to be used in order to prepare tarball. I think that one should be able to prepare tarball the standard way (./autogen.sh && make && make install && make distcheck), without this workaround, as I believe that there's not much point in adding Git hash & branch when user is not building from the source tree anyway. For tarball releases, I'd drop the Git info altogether.

Moreover, when I make tarball now, this is what the GIT_BRANCH is expanded to:

GIT_BRANCH=`echo " (HEAD, PAN_0_134pre1, pmkovar/master-pre, pmkovar/master, master)"

I'm not sure we want this useless info in tarballs. Also note the leading space that seems to be redundant there.
Comment 9 Kenneth Haley 2011-01-27 01:11:43 UTC
First, the leading space is generated by git no that it matters since the awk expression will reduce that down to 'master'.  It always takes the last entry.

Second, Pan has almost always had some revision info in it, whether it was cvs/svn revisions or the git hash.  That info is in the about dialog so the user can specify the exact version when reporting a bug.  It is also sent out in a header with every message sent.

Also there is no way to tell if the tarball was created by you for release or if it was generated by gnome/github, which was the original reason I added support for git archive.

I've just added a new trick to the integration branch.  Every time configure is run it outputs the GIT_REV to a file to be used when no other git revision info can be found.  And if that fails it sets GIT_REV='Unknown'.  This should allow you to use your normal method.
Comment 10 Petr Kovar 2011-01-29 17:39:08 UTC
Hey Kenneth, thank you! I finally got to test it, works flawlessly, and the dist process is much more straightforward now.
Comment 11 Petr Kovar 2011-02-19 18:32:49 UTC
Merged into GNOME master.

This problem has been fixed in our software repository. The fix will go into
the next software release. Thank you for your bug report.