dbginfo.sh needs to be included in s390-tools

FYI, here is a full list of binaries/things that are available, yet we are not currently shipping.

dh_install --list-missing
dh_install: sbin/dasdstat exists in debian/tmp but is not installed to anywhere
dh_install: sbin/cio_ignore exists in debian/tmp but is not installed to anywhere
dh_install: sbin/qethqoat exists in debian/tmp but is not installed to anywhere
dh_install: sbin/lsscm exists in debian/tmp but is not installed to anywhere
dh_install: sbin/scsi_logging_level exists in debian/tmp but is not installed to anywhere
dh_install: sbin/znetconf exists in debian/tmp but is not installed to anywhere
dh_install: sbin/dbginfo.sh exists in debian/tmp but is not installed to anywhere
dh_install: sbin/ttyrun exists in debian/tmp but is not installed to anywhere
dh_install: sbin/tape390_crypt exists in debian/tmp but is not installed to anywhere
dh_install: sbin/zfcpdbf exists in debian/tmp but is not installed to anywhere
dh_install: sbin/chchp exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/ziomon exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/cpacfstatsd exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/ziomon_fcpconf exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/ziorep_traffic exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/chiucvallow exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/ziorep_utilization exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/lshmc exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/ip_watcher.pl exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/chcpumf exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/xcec-bridge exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/ziorep_config exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/ziomon_zfcpdd exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/ziomon_mgr exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/lsiucvallow exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/mon_procd exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/start_hsnc.sh exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/mon_fsstatd exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/cpuplugd exists in debian/tmp but is not installed to anywhere
dh_install: usr/sbin/ziomon_util exists in debian/tmp but is not installed to anywhere
dh_install: usr/share/s390-tools/cpumf/cpum-cf-hw-counter.map exists in debian/tmp but is not installed to anywhere
dh_install: usr/share/s390-tools/cpumf/cpum-cf-extended-z196.ctr exists in debian/tmp but is not installed to anywhere
dh_install: usr/share/s390-tools/cpumf/cpum-sf-modes.ctr exists in debian/tmp but is not installed to anywhere
dh_install: usr/share/s390-tools/cpumf/cpum-cf-extended-z10.ctr exists in debian/tmp but is not installed to anywhere
dh_install: usr/share/s390-tools/cpumf/cpum-cf-extended-zEC12.ctr e...

------- Comment From <email address hidden> 2016-02-02 03:06 EDT-------
HI,

(In reply to comment #6)
> FYI, here is a full list of binaries/things that are available, yet we are
> not currently shipping.
>

the list is long and I already opened few debian bugs to include several utilities. Also I asked whether to provide subpackages, for example, for ziomon. It is an FCP performance monitor for s390 and depends on further utilities which mignt not be required in every installation.

This bug was fixed in the package s390-tools - 1.32.0-2ubuntu2

---------------
s390-tools (1.32.0-2ubuntu2) xenial; urgency=medium

  [ Dimitri John Ledkov ]
  * Support DESTDIR in the makefiles.
  * Modernise packaging.
  * Apply patch to build zipl without PIE, even if enabled by
    default in the toolchain.
  * Enable verbose builds
  * Enable support for CFLAGS, and thus build optimized binaries,
    with debug symbols stored in debugsymbols package.
  * Enable hardening build flags.
  * Enable parallel build.
  * Fix spelling in binaries.
  * Fix one more LO macro in vmur man page.
  * Simplify synopsis.

  [ dann frazier ]
  * Add dbginfo.sh. (Closes: #807442, LP: #1539719)
    - dbginfo.sh-umask.patch: Avoid leaking content to unprivileged users.
    - dbginfo.sh-warn.patch: Warn users about the sensitivity of the data
      this tool collects.

  [ Hendrik Brueckner ]
  * Clean up lsluns comment leftovers
  * Install additional management utilities: lschp, chchp, dasdstat,
    cio_ignore, and znetconf with its related files. (Closes: #812092, LP:
    1536559)

 -- Dimitri John Ledkov <email address hidden> Tue, 02 Feb 2016 14:13:33 +0000

------- Comment From <email address hidden> 2016-02-03 13:59 EDT-------
dbginfo.sh was modified by canonical. Before it collects data, it aks the user, whether he really wants to do that.

see here:
######################################
# Verification to run as root
#
if test "" -ne 0; then
echo "${SCRIPTNAME}: Error: You must be user root to run \"${SCRIPTNAME}\"!"
exit 1
fi

+ echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
+ echo " Warning: The archive created by this utility will contain sensitive"
+ echo " information including, but not limited to:"
+ echo " - configuration files"
+ echo " - log files"
+ echo " - hardware state information"
+ echo " - running process state and command line arguments"
+ echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
+ echo ""
+ echo -n " Do you wish to continue? [y/N]> "
+ read resp
+ case "$resp" in
+ y|Y)
+ :
+ ;;
+ *)
+ echo "OK, exiting."
+ exit 0
+ esac
+
+
#######################################
# Parsing the command line
#

IBM can not accept this:
1. It is ensured by the above code, that only the root user is running this script. By default, it is assumed, that the roor user knows what he has to do and what not.
2. For providing debugging information, it is in some cases required to either start dgbinfo.sh immediately at a certain point, or to start it by any automated trigger. The first case will delay the execution of dbginfo.sh, the second will prevent it.
3. For automated testing we often collect data via dbginfo.sh triggered by a script. Same problem, this will not work, or needs some workaround just for this particular flavour of dbginfo.sh

I hereby request to pick up the unmodified code of dbginfo.sh as of s390-tools 1.32.0 provided by IBM.

------- Comment From <email address hidden> 2016-02-05 10:12 EDT-------
(In reply to comment #11)
>
> I hereby request to pick up the unmodified code of dbginfo.sh as of
> s390-tools 1.32.0 provided by IBM.

... which has now been superseded by version 1.33.0 - which has been requested today via LTC bug 133656.

Hello,

I will disable patches to dbginfo.sh. However, note that in a way I dislike dbginfo.sh.

First of all the name of the script is an awkward one, very generic and violates Debian Policy (which ubuntu also follows), specifically that the binary ends with an extension.

Secondly, using custom, per-architecture scripts does not follow current best practices of sustaining & support engineering. The currently upcoming framework for such purposes is sosreport http://sos.readthedocs.org/en/latest/ and it is used by Canonical engineers and engineers of other supported distributions on z Series. Integrating into sosreport with sosreport specific plugins would be great.

On Ubuntu, we also have a combination of apport & whoopsie. The former collects a lot of debug infomration about running system, and specific packages via hooks if a report got initiated manually or due to a crash. Apport comes with a privacy policy, and uploads things privately over encrypted connections into launchpad for further follow-up. Also apport crash files can be off-loaded from a system and reported using another system (e.g. scp .crash from mainframe onto laptop, report from a laptop). Secondly there are automatic crash reports, which one can opt-into on server, to upload annomyzed crash data into https://errors.ubuntu.com/ ( aka whoopsie-daisy) crash data from that website is used to monitor, track, identify and prioritise bugs and crashes. One in particular useful feature is that canaries software updates use that data, for example if unforseen packages/daemons start to crash due to an SRU and/or Security Update, such updates may be pulled or further-fixed to prevent regressions in a stable release.

I hope we can integrate hardware specific debugging functionality into the existing debug and support frameworks, rather than requiring custom, mainframe specific, actions from canonical support and ubuntu users. On ubuntu, we request our users to simply do $ ubuntu-bug foo -> to collect all relevant information, and securely communicate it about any problem faced, be that installer, a particular package name and/or binary name.

Regards,

Dimitri.

This bug was fixed in the package s390-tools - 1.33.0-0ubuntu2

---------------
s390-tools (1.33.0-0ubuntu2) xenial; urgency=medium

  [ Hendrik Brueckner ]
  * Add zfcp monitoring and reporting tools (ziomon) (Closes: #812588)
    LP: #1540425.

  [ Dimitri John Ledkov ]
  * Drop dependencies/recommendencies for ziomon to Suggests, to avoid
    pulling those large packages, on all installation types (including
    virtual machines, cloud images, lxc/lxd/docker containers)

  * Possibly it is time to split s390-tools into essential, and optional
    binary packages with correct dependencies.

 -- Dimitri John Ledkov <email address hidden> Tue, 09 Feb 2016 11:38:46 +0000

------- Comment From <email address hidden> 2016-02-10 14:10 EDT-------
Successfully verified on s390-tools 1.33.0-0ubuntu2.
Closed.