From: Emily Shaffer <emilyshaffer@google.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3 3/9] bugreport: add version and system information
Date: Fri, 8 Nov 2019 13:48:37 -0800 [thread overview]
Message-ID: <20191108214757.GB22855@google.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1910281432180.46@tvgsbejvaqbjf.bet>
On Mon, Oct 28, 2019 at 02:49:29PM +0100, Johannes Schindelin wrote:
> Hi Emily,
>
> On Thu, 24 Oct 2019, Emily Shaffer wrote:
>
> > diff --git a/bugreport.c b/bugreport.c
> > new file mode 100644
> > index 0000000000..ada54fe583
> > --- /dev/null
> > +++ b/bugreport.c
> > @@ -0,0 +1,55 @@
> > +#include "cache.h"
> > +
> > +#include "bugreport.h"
> > +#include "help.h"
> > +#include "run-command.h"
> > +#include "version.h"
> > +
> > +void get_system_info(struct strbuf *sys_info)
> > +{
> > + struct child_process cp = CHILD_PROCESS_INIT;
> > + struct strbuf std_out = STRBUF_INIT;
> > +
> > + strbuf_reset(sys_info);
> > +
> > + // get git version from native cmd
>
> Please use C-style comments instead of C++ ones.
>
> > + strbuf_addstr(sys_info, "git version: ");
> > + strbuf_addstr(sys_info, git_version_string);
> > + strbuf_complete_line(sys_info);
> > +
> > + // system call for other version info
> > + argv_array_push(&cp.args, "uname");
> > + argv_array_push(&cp.args, "-a");
> > + capture_command(&cp, &std_out, 0);
>
> Mmmkay. I am not too much of a fan of relying on the `uname` executable,
> as it can very well be a 32-bit `uname.exe` on Windows, which obviously
> would _not_ report the architecture of the machine, but something
> misleading.
>
> Why not use the `uname()` function (that we even define in
> `compat/mingw.c`)?
Very glad to have your review and point this kind of thing out. :) It
simplifies the code, too. I wasn't sure about these system calls, so I
appreciate you suggesting alternatives.
>
> Also, why not include the same information as `git version
> --build-options`, most importantly `GIT_HOST_CPU`?
>
> In any case, if you are capturing the output of `uname -a`, you
> definitely will want to pass the `RUN_COMMAND_STDOUT_TO_STDERR` flag (in
> case, say, the MSYS2 `uname.exe` fails with those dreaded Cygwin error
> messages like "*** fatal error - add_item
> ("\??\D:\git\installation\Git", "/", ...) failed, errno 1").
>
> > +
> > + strbuf_addstr(sys_info, "uname -a: ");
> > + strbuf_addbuf(sys_info, &std_out);
> > + strbuf_complete_line(sys_info);
> > +
> > + argv_array_clear(&cp.args);
> > + strbuf_reset(&std_out);
> > +
> > +
> > + argv_array_push(&cp.args, "curl-config");
> > + argv_array_push(&cp.args, "--version");
> > + capture_command(&cp, &std_out, 0);
>
> This will be almost certainly be incorrect, as most _regular_ users
> won't have `curl-config`. I know, it is easy to forget that most Git
> users are no hard-core C developers ;-)
Heresy! :)
>
> A better alternative would be to use `curl_version()`, guarded, of
> course, by `#ifndef NO_CURL`...
>
> > +
> > + strbuf_addstr(sys_info, "curl-config --version: ");
> > + strbuf_addbuf(sys_info, &std_out);
> > + strbuf_complete_line(sys_info);
> > +
> > + argv_array_clear(&cp.args);
> > + strbuf_reset(&std_out);
> > +
> > +
> > + argv_array_push(&cp.args, "ldd");
> > + argv_array_push(&cp.args, "--version");
> > + capture_command(&cp, &std_out, 0);
>
> Again, this command will only be present in few setups. I am not
> actually sure that the output of this is interesting to begin with.
It was a suggestion, I believe, from Jonathan Nieder.
>
> What I _do_ think is that a much more interesting piece of information
> would be the exact GLIBC version, the OS name and the OS version.
The glibc version is easy; I've done that. It certainly looks nicer than
the ldd call.
I guess I may be missing something, because as I start to look into how
to the OS info, I fall down a hole of many, many preprocessor defines to
check. If that's the approach you want me to take, just say the word,
but it will be ugly :) I suppose I had hoped the uname info would give us
a close enough idea that full OS info isn't necessary.
>
> > +
> > + strbuf_addstr(sys_info, "ldd --version: ");
> > + strbuf_addbuf(sys_info, &std_out);
> > + strbuf_complete_line(sys_info);
> > +
> > + argv_array_clear(&cp.args);
> > + strbuf_reset(&std_out);
> > +}
> > diff --git a/bugreport.h b/bugreport.h
> > new file mode 100644
> > index 0000000000..ba216acf3f
> > --- /dev/null
> > +++ b/bugreport.h
> > @@ -0,0 +1,7 @@
> > +#include "strbuf.h"
> > +
> > +/**
> > + * Adds the Git version, `uname -a`, and `curl-config --version` to sys_info.
> > + * The previous contents of sys_info will be discarded.
> > + */
> > +void get_system_info(struct strbuf *sys_info);
> > diff --git a/builtin/bugreport.c b/builtin/bugreport.c
> > index 2ef16440a0..7232d31be7 100644
> > --- a/builtin/bugreport.c
> > +++ b/builtin/bugreport.c
> > @@ -1,4 +1,5 @@
> > #include "builtin.h"
> > +#include "bugreport.h"
> > #include "stdio.h"
> > #include "strbuf.h"
> > #include "time.h"
> > @@ -27,6 +28,13 @@ int get_bug_template(struct strbuf *template)
> > return 0;
> > }
> >
> > +void add_header(FILE *report, const char *title)
> > +{
> > + struct strbuf buffer = STRBUF_INIT;
> > + strbuf_addf(&buffer, "\n\n[%s]\n", title);
> > + strbuf_write(&buffer, report);
>
> This leaks `buffer`. Why not write into `report` via `fprintf()`
> directly?
Rather, to match the style of the rest of the builtin, modified
get_header to add the header to a passed-in strbuf instead of
modifying the file directly.
>
> Ciao,
> Dscho
>
> > +}
> > +
> > int cmd_bugreport(int argc, const char **argv, const char *prefix)
> > {
> > struct strbuf buffer = STRBUF_INIT;
> > @@ -43,6 +51,11 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
> > get_bug_template(&buffer);
> > strbuf_write(&buffer, report);
> >
> > + // add other contents
> > + add_header(report, "System Info");
> > + get_system_info(&buffer);
> > + strbuf_write(&buffer, report);
> > +
> > fclose(report);
> >
> > launch_editor(report_path.buf, NULL, NULL);
> > --
> > 2.24.0.rc0.303.g954a862665-goog
> >
> >
Based on Dscho's comments, each piece of system info is gathered
differently enough that I will do each in an independent commit now.
next prev parent reply other threads:[~2019-11-08 21:48 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-15 2:34 [PATCH] bugreport: add tool to generate debugging info Emily Shaffer
2019-08-15 14:15 ` Derrick Stolee
2019-08-15 14:36 ` Junio C Hamano
2019-08-15 22:52 ` Emily Shaffer
2019-08-15 23:40 ` Junio C Hamano
2019-08-16 1:25 ` Emily Shaffer
2019-08-16 16:41 ` Junio C Hamano
2019-08-16 19:08 ` Emily Shaffer
2019-08-15 20:07 ` Johannes Schindelin
2019-08-15 22:24 ` Emily Shaffer
2019-08-16 20:19 ` Johannes Schindelin
2019-08-15 20:13 ` Emily Shaffer
2019-08-15 18:10 ` Junio C Hamano
2019-08-15 21:52 ` Emily Shaffer
2019-08-15 22:29 ` Junio C Hamano
2019-08-15 22:54 ` Emily Shaffer
2019-08-17 0:39 ` [PATCH v2 0/2] add git-bugreport tool Emily Shaffer
2019-08-17 0:39 ` [PATCH v2 1/2] bugreport: add tool to generate debugging info Emily Shaffer
2019-08-17 0:39 ` [PATCH v2 2/2] bugreport: generate config whitelist based on docs Emily Shaffer
2019-08-17 20:38 ` Martin Ågren
2019-08-21 17:40 ` Emily Shaffer
2019-10-25 2:51 ` [PATCH v3 0/9] add git-bugreport tool Emily Shaffer
2019-10-25 2:51 ` [PATCH v3 1/9] bugreport: add tool to generate debugging info Emily Shaffer
2019-10-29 20:29 ` Josh Steadmon
2019-11-16 3:11 ` Junio C Hamano
2019-11-19 20:25 ` Emily Shaffer
2019-11-19 23:24 ` Johannes Schindelin
2019-11-20 0:37 ` Junio C Hamano
2019-11-20 10:51 ` Johannes Schindelin
2019-11-19 23:31 ` Johannes Schindelin
2019-11-20 0:39 ` Junio C Hamano
2019-11-20 2:09 ` Emily Shaffer
2019-11-20 0:32 ` Junio C Hamano
2019-10-25 2:51 ` [PATCH v3 2/9] bugreport: generate config whitelist based on docs Emily Shaffer
2019-10-28 13:27 ` Johannes Schindelin
2019-10-25 2:51 ` [PATCH v3 3/9] bugreport: add version and system information Emily Shaffer
2019-10-28 13:49 ` Johannes Schindelin
2019-11-08 21:48 ` Emily Shaffer [this message]
2019-11-11 13:48 ` Johannes Schindelin
2019-11-14 21:42 ` Emily Shaffer
2019-10-29 20:43 ` Josh Steadmon
2019-10-25 2:51 ` [PATCH v3 4/9] bugreport: add config values from whitelist Emily Shaffer
2019-10-28 14:14 ` Johannes Schindelin
2019-12-11 20:48 ` Emily Shaffer
2019-12-15 17:30 ` Johannes Schindelin
2019-10-29 20:58 ` Josh Steadmon
2019-10-30 1:37 ` Junio C Hamano
2019-11-14 21:55 ` Emily Shaffer
2019-10-25 2:51 ` [PATCH v3 5/9] bugreport: collect list of populated hooks Emily Shaffer
2019-10-28 14:31 ` Johannes Schindelin
2019-12-11 20:51 ` Emily Shaffer
2019-12-15 17:40 ` Johannes Schindelin
2019-10-25 2:51 ` [PATCH v3 6/9] bugreport: count loose objects Emily Shaffer
2019-10-28 15:07 ` Johannes Schindelin
2019-12-10 22:34 ` Emily Shaffer
2019-10-29 21:18 ` Josh Steadmon
2019-10-25 2:51 ` [PATCH v3 7/9] bugreport: add packed object summary Emily Shaffer
2019-10-28 15:43 ` Johannes Schindelin
2019-12-11 0:29 ` Emily Shaffer
2019-12-11 13:37 ` Johannes Schindelin
2019-12-11 20:52 ` Emily Shaffer
2019-10-25 2:51 ` [PATCH v3 8/9] bugreport: list contents of $OBJDIR/info Emily Shaffer
2019-10-28 15:51 ` Johannes Schindelin
2019-10-25 2:51 ` [PATCH v3 9/9] bugreport: print contents of alternates file Emily Shaffer
2019-10-28 15:57 ` Johannes Schindelin
2019-11-19 20:40 ` Emily Shaffer
2019-10-29 1:54 ` [PATCH v3 0/9] add git-bugreport tool Junio C Hamano
2019-10-29 11:13 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191108214757.GB22855@google.com \
--to=emilyshaffer@google.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.