From nobody@FreeBSD.org  Thu Nov 22 08:30:19 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 66E61FCD
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 22 Nov 2012 08:30:19 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 42E8A8FC08
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 22 Nov 2012 08:30:19 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.5/8.14.5) with ESMTP id qAM8UIc1000430
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 22 Nov 2012 08:30:18 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.5/8.14.5/Submit) id qAM8UIXP000429;
	Thu, 22 Nov 2012 08:30:18 GMT
	(envelope-from nobody)
Message-Id: <201211220830.qAM8UIXP000429@red.freebsd.org>
Date: Thu, 22 Nov 2012 08:30:18 GMT
From: vermaden <vermaden@interia.pl>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Brain-dead simple change to ZFS error description link prefix
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         173830
>Category:       kern
>Synopsis:       [zfs] Brain-dead simple change to ZFS error description link prefix
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-fs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 22 08:40:00 UTC 2012
>Closed-Date:    
>Last-Modified:  Mon Dec 03 04:49:54 UTC 2012
>Originator:     vermaden
>Release:        (does not matter)
>Organization:
>Environment:
(does not matter)
>Description:
Hi,

When something in ZFS/ZPOOL fails, it displays links to error description to http://www.sun.com/msg/${ERROR} but these links do not work anymore after Oracle acquired Sun.

It should be brain-dead easy to change all occurrences in the source from  not working http://www.sun.com/msg to https://www.illumos.org/msg prefix.

This should be helpful:

% grep -r 'http://www.sun.com/msg' /usr/src 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/os/.svn/text-base/fm.c.svn-base:static const char *fm_url = "http://www.sun.com/msg";
/usr/src/sys/cddl/contrib/opensolaris/uts/common/os/fm.c:static const char *fm_url = "http://www.sun.com/msg";
/usr/src/tools/regression/zfs/zpool/replace/raidz2.t:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/raidz2.t:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/raidz2.t:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/raidz2.t:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/raidz2.t:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/mirror.t:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/.svn/text-base/raidz1.t.svn-base:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/.svn/text-base/log.t.svn-base:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/.svn/text-base/log.t.svn-base:  echo "   see: http://www.sun.com/msg/ZFS-8000-2Q"
/usr/src/tools/regression/zfs/zpool/replace/.svn/text-base/mirror.t.svn-base:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/.svn/text-base/raidz2.t.svn-base:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/.svn/text-base/raidz2.t.svn-base:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/.svn/text-base/raidz2.t.svn-base:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/.svn/text-base/raidz2.t.svn-base:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/.svn/text-base/raidz2.t.svn-base:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/raidz1.t:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/log.t:  echo "   see: http://www.sun.com/msg/ZFS-8000-4J"
/usr/src/tools/regression/zfs/zpool/replace/log.t:  echo "   see: http://www.sun.com/msg/ZFS-8000-2Q"

Regards,
vermaden
>How-To-Repeat:
Broke ZFS and try to follow the suggested link ;)
>Fix:
(not tested)

# find /usr/src -type -f -exec sed -i '' s/http:\/\/www.sun.com\/msg/https:\/\/www.illumos.org\/msg/g {} ';'

>Release-Note:
>Audit-Trail:

From: Andriy Gapon <avg@FreeBSD.org>
To: vermaden <vermaden@interia.pl>
Cc: bug-followup@FreeBSD.org
Subject: Re: amd64/173830: Brain-dead simple change to ZFS error description
 link prefix
Date: Thu, 22 Nov 2012 15:59:11 +0200

 > When something in ZFS/ZPOOL fails, it displays links to error description to http://www.sun.com/msg/${ERROR} but these links do not work anymore after Oracle acquired Sun.
 > 
 > It should be brain-dead easy to change all occurrences in the source from  not working http://www.sun.com/msg to https://www.illumos.org/msg prefix.
 
 This is already done for all end-user visible messages.
 You can double-check the list below yourself.
 
 You could be more specific about what message you got, in what situation, with
 what tool and with *what FreeBSD version*.
 
 Additionally, please be more attentive when filing PRs, your report does not seem
 to be amd64-specific.
 
 -- 
 Andriy Gapon

From: vermaden <vermaden@interia.pl>
To: Andriy Gapon <avg@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: amd64/173830: Brain-dead simple change to ZFS error description
 link prefix
Date: Fri, 23 Nov 2012 06:59:40 +0100

 > Additionally, please be more attentive when filing PRs, your report does not seem
 > to be amd64-specific.
 
 So the question is, why keep dead links if one sed command can switch them to working equivalents? ( no matter if they are regression tools or end-user tools)
 
 About the category, there is no ZFS or FS category, so I thought that as I use amd64 it would be a good idea, it wasn't.
 
 Could You tell me which category should I choose next time with filesystem or ZFS problem? kern?
 
 Regards,
 vermaden
 
From: Andriy Gapon <avg@FreeBSD.org>
To: vermaden <vermaden@interia.pl>
Cc: bug-followup@FreeBSD.org
Subject: Re: amd64/173830: Brain-dead simple change to ZFS error description
 link prefix
Date: Fri, 23 Nov 2012 09:51:02 +0200

 on 23/11/2012 07:59 vermaden said the following:
 > So the question is, why keep dead links if one sed command can switch them to
 > working equivalents?
 
 Please first answer all the questions that I asked.
 
 -- 
 Andriy Gapon

From: Andriy Gapon <avg@FreeBSD.org>
To: vermaden <vermaden@interia.pl>
Cc: bug-followup@FreeBSD.org
Subject: Re: amd64/173830: Brain-dead simple change to ZFS error description
 link prefix
Date: Fri, 23 Nov 2012 09:56:58 +0200

 on 23/11/2012 07:59 vermaden said the following:
 > Could You tell me which category should I choose next time with filesystem or
 > ZFS problem? kern?
 
 If you see a problem with a kernel side of ZFS or a generic ZFS problem - then,
 yes, 'kern'.
 If it is with a specific userland utility, then 'bin' would be better.
 If it is with any ZFS documentation, then 'doc'.
 If it is arch-specific, e.g. a problem occurs on i386 but not on amd64 or vice
 versa, then either 'i386' or 'amd64' or etc.
 
 -- 
 Andriy Gapon

From: vermaden <vermaden@interia.pl>
To: Andriy Gapon <avg@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: amd64/173830: Brain-dead simple change to ZFS error description
 link prefix
Date: Fri, 23 Nov 2012 12:27:25 +0100

 "Andriy Gapon" <avg@FreeBSD.org>:
 > on 23/11/2012 07:59 vermaden said the following:
 > > Could You tell me which category should I choose next time
 > > with filesystem or ZFS problem? kern?
 > 
 > If you see a problem with a kernel side of ZFS or a generic ZFS
 > problem - then, yes, 'kern'.
 > If it is with a specific userland utility, then 'bin' would be
 > better.
 > If it is with any ZFS documentation, then 'doc'.
 > If it is arch-specific, e.g. a problem occurs on i386 but not on
 > amd64 or vice versa, then either 'i386' or 'amd64' or etc.
 
 Ok, thanks for clarification, so I assume, that this one would go
 under 'bin' as this is a message from an userland utility.
 
 "Andriy Gapon" <avg@FreeBSD.org>:
 > on 23/11/2012 07:59 vermaden said the following:
 > > So the question is, why keep dead links if one sed
 > > command can switch them to working equivalents?
 > 
 > Please first answer all the questions that I asked.
 
 The FreeBSD version is 9.0-STABLE built from sources
 from about 9.1-RC3, here is the exact uname -a message:
 
 FreeBSD e6400.domain.com 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r243107: Fri Nov 16 07:41:05 CET 2012    root@e6400.domain.com:/usr/obj/usr/src/sys/GENERIC  amd64
 
 Regards,
 vermaden

From: Andriy Gapon <avg@FreeBSD.org>
To: vermaden <vermaden@interia.pl>
Cc: bug-followup@FreeBSD.org
Subject: Re: amd64/173830: Brain-dead simple change to ZFS error description
 link prefix
Date: Fri, 23 Nov 2012 13:36:07 +0200

 on 23/11/2012 13:27 vermaden said the following:
 > "Andriy Gapon" <avg@FreeBSD.org>:
 >> Please first answer all the questions that I asked.
 > 
 > The FreeBSD version is 9.0-STABLE built from sources
 > from about 9.1-RC3, here is the exact uname -a message:
 > 
 > FreeBSD e6400.domain.com 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r243107: Fri Nov 16 07:41:05 CET 2012    root@e6400.domain.com:/usr/obj/usr/src/sys/GENERIC  amd64
 
 I'll quote my questions again:
 
 > You could be more specific about what message you got, in what situation, with
 > what tool and with *what FreeBSD version*.
 
 So you answered only the last of them.
 Why is it so difficult to be cooperative with developers?
 Especially when I you'd like to get some work done by them.
 
 -- 
 Andriy Gapon

From: vermaden <vermaden@interia.pl>
To: Andriy Gapon <avg@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: amd64/173830: Brain-dead simple change to ZFS error description
 link prefix
Date: Sat, 24 Nov 2012 17:05:58 +0100

 "Andriy Gapon" <avg@FreeBSD.org>:
 > So you answered only the last of them.
 > Why is it so difficult to be cooperative with developers?
 > Especially when I you'd like to get some work done by them.
 > 
 > -- 
 > Andriy Gapon
 
 I found that article:
 http://blog.alainodea.com/en/article/440/experiments-with-zfs-failure-modes-and-autogrowth
 
 and I recall that FreeBSD zpool always referenced to the
 htttp://www.sun.com/msg/... so I checked what is in the
 FreeBSD source and found a lot references to the old and
 not working htttp://www.sun.com/msg/... domain. So I
 willed that PR, so the non-working domain would be
 changed to the working one.
 
 I did not get any errors. did not got any error message etc.
 
 Regards,
 vermaden

From: Andriy Gapon <avg@FreeBSD.org>
To: vermaden <vermaden@interia.pl>
Cc: bug-followup@FreeBSD.org
Subject: Re: amd64/173830: Brain-dead simple change to ZFS error description
 link prefix
Date: Sat, 24 Nov 2012 20:57:17 +0200

 on 24/11/2012 18:05 vermaden said the following:
 
 > I found that article:
 > http://blog.alainodea.com/en/article/440/experiments-with-zfs-failure-modes-and-autogrowth
 > 
 > and I recall that FreeBSD zpool always referenced to the
 > htttp://www.sun.com/msg/... so I checked what is in the
 > FreeBSD source and found a lot references to the old and
 > not working htttp://www.sun.com/msg/... domain. So I
 > willed that PR, so the non-working domain would be
 > changed to the working one.
 > 
 > I did not get any errors. did not got any error message etc.
 
 Oh, I see.  Thank you for the explanation.
 As far as I understand the situation, the end-users should not get any messages
 with the incorrect URLs with recent versions of FreeBSD.
 
 We indeed should fix all the occurrences of sun.com URLs in our sources, but
 it's not clear if it's best to do that directly or through vendor imports from
 Illumos.  This is really a low-priority task because some of the occurrences are
 not used at all.
 
 -- 
 Andriy Gapon
Responsible-Changed-From-To: freebsd-amd64->freebsd-fs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Dec 3 04:48:26 UTC 2012 
Responsible-Changed-Why:  
reclassify. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=173830 
>Unformatted:
