Re: [Bug debuginfod/28034] client-side %-escape url characters

2021-08-27 Thread Noah Sanci via Elfutils-devel
Hello,

Here is an updated patch, using memmove. Much smaller.

Thanks for the suggestions,

Noah Sanci


On Thu, Aug 26, 2021 at 5:02 PM Frank Ch. Eigler  wrote:
>
> Hi -
>
> >/* PR28034 escape characters in completed url to %hh format. */
> > -  char *escaped_string;
> > -  escaped_string = curl_easy_escape(data[i].handle, filename, 0);
> > -  if (!escaped_string)
> > +  char escaped_string[PATH_MAX] = {'\0'};
> > +  char *loc = (char *) filename;
> > +  char *loc2;
> > +  char *tmp;
> > +  for(size_t j = 0; j < strlen(filename); ++j)
> >  {
> > -  rc = -ENOMEM;
> > -  goto out2;
> > +  loc2 = strstr(loc, "/");
> > +  // If the first character is a '/'
> > [...]
>
> Holy cow that's a lot of work to do it this way.
> A couple of alternatives:
>
> - ditch curl_easy_escape :-( and use a
>   malloc(strlen(x)*3)
>   byte-by-byte copy from source string into destination
> if not [a-zA-Z0-9/.~] then %-escape
>
> or:
> - keep curl_easy_escape and postprocess
>   byte-by-byte examine the result of curl_easy_escape
>   - if seeing a "%2F", replace the % with a / and memmove the
> rest of the string 2 bytes ahead
>
> It shouldn't need strtok or strstr or a lot of logic or stuff like
> that really.
>
> - FChE
>
From de7e50955dba711aeee33196bf2bfea3c47696f7 Mon Sep 17 00:00:00 2001
From: Noah Sanci 
Date: Fri, 16 Jul 2021 15:16:20 -0400
Subject: [PATCH] debuginfod: PR28034 - client-side %-escape url characters

When requesting some source files, some URL-inconvenient chars
sometimes pop up.  Example from f33 libstdc++:
/buildid/44d8485cb75512c2ca5c8f70afbd475cae30af4f/source/usr/src/debug/
gcc-10.3.1-1.fc33.x86_64/obj-x86_64-redhat-linux/x86_64-redhat-linux/
libstdc++-v3/src/c++11/../../../../../libstdc++-v3/src/c++11/
condition_variable.cc
As this URL is passed into debuginfod's handler_cb, it appears that the
+ signs are helpfully unescaped to spaces by libmicrohttpd, which
'course breaks everything.
In order to ensure the server properly parses urls such as this one,
%-escape characters on the client side so that the correct url
is preserved and properly processed on the server side.

https://sourceware.org/bugzilla/show_bug.cgi?id=28034

Signed-off-by: Noah Sanci 
---
 debuginfod/debuginfod-client.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index 7d4b220f..eb49b583 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -905,13 +905,25 @@ debuginfod_query_server (debuginfod_client *c,
 {
   /* PR28034 escape characters in completed url to %hh format. */
   char *escaped_string;
+  char *loc;
   escaped_string = curl_easy_escape(data[i].handle, filename, 0);
   if (!escaped_string)
 {
   rc = -ENOMEM;
   goto out2;
 }
-  snprintf(data[i].url, PATH_MAX, "%s/%s/%s/%s", server_url,
+
+  loc = strstr(escaped_string, "%2F");
+  if (loc != NULL)
+do
+  {
+loc[0] = '/';
+// pull the string back after replacement
+memmove(loc+1,loc+3,strlen(loc+3));
+escaped_string[strlen(escaped_string) - 1] = '\0';
+escaped_string[strlen(escaped_string) - 1] = '\0';
+  } while( (loc = strstr(loc, "%2F")) );
+  snprintf(data[i].url, PATH_MAX, "%s/%s/%s%s", server_url,
build_id_bytes, type, escaped_string);
   curl_free(escaped_string);
 }
-- 
2.31.1



Re: [Bug debuginfod/28034] client-side %-escape url characters

2021-08-27 Thread Noah Sanci via Elfutils-devel
Hello

Update 2, no longer append nulls unnecessarily.

-Noah Sanci

On Fri, Aug 27, 2021 at 10:44 AM Noah Sanci  wrote:
>
> Hello,
>
> Here is an updated patch, using memmove. Much smaller.
>
> Thanks for the suggestions,
>
> Noah Sanci
>
>
> On Thu, Aug 26, 2021 at 5:02 PM Frank Ch. Eigler  wrote:
> >
> > Hi -
> >
> > >/* PR28034 escape characters in completed url to %hh format. */
> > > -  char *escaped_string;
> > > -  escaped_string = curl_easy_escape(data[i].handle, filename, 0);
> > > -  if (!escaped_string)
> > > +  char escaped_string[PATH_MAX] = {'\0'};
> > > +  char *loc = (char *) filename;
> > > +  char *loc2;
> > > +  char *tmp;
> > > +  for(size_t j = 0; j < strlen(filename); ++j)
> > >  {
> > > -  rc = -ENOMEM;
> > > -  goto out2;
> > > +  loc2 = strstr(loc, "/");
> > > +  // If the first character is a '/'
> > > [...]
> >
> > Holy cow that's a lot of work to do it this way.
> > A couple of alternatives:
> >
> > - ditch curl_easy_escape :-( and use a
> >   malloc(strlen(x)*3)
> >   byte-by-byte copy from source string into destination
> > if not [a-zA-Z0-9/.~] then %-escape
> >
> > or:
> > - keep curl_easy_escape and postprocess
> >   byte-by-byte examine the result of curl_easy_escape
> >   - if seeing a "%2F", replace the % with a / and memmove the
> > rest of the string 2 bytes ahead
> >
> > It shouldn't need strtok or strstr or a lot of logic or stuff like
> > that really.
> >
> > - FChE
> >
From f5c7c00c76b200675556a0ecc6bd8a5fdc7a30ea Mon Sep 17 00:00:00 2001
From: Noah Sanci 
Date: Fri, 16 Jul 2021 15:16:20 -0400
Subject: [PATCH] debuginfod: PR28034 - client-side %-escape url characters

When requesting some source files, some URL-inconvenient chars
sometimes pop up.  Example from f33 libstdc++:
/buildid/44d8485cb75512c2ca5c8f70afbd475cae30af4f/source/usr/src/debug/
gcc-10.3.1-1.fc33.x86_64/obj-x86_64-redhat-linux/x86_64-redhat-linux/
libstdc++-v3/src/c++11/../../../../../libstdc++-v3/src/c++11/
condition_variable.cc
As this URL is passed into debuginfod's handler_cb, it appears that the
+ signs are helpfully unescaped to spaces by libmicrohttpd, which
'course breaks everything.
In order to ensure the server properly parses urls such as this one,
%-escape characters on the client side so that the correct url
is preserved and properly processed on the server side.

https://sourceware.org/bugzilla/show_bug.cgi?id=28034

Signed-off-by: Noah Sanci 
---
 debuginfod/debuginfod-client.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index 7d4b220f..6db82f79 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -905,13 +905,23 @@ debuginfod_query_server (debuginfod_client *c,
 {
   /* PR28034 escape characters in completed url to %hh format. */
   char *escaped_string;
+  char *loc;
   escaped_string = curl_easy_escape(data[i].handle, filename, 0);
   if (!escaped_string)
 {
   rc = -ENOMEM;
   goto out2;
 }
-  snprintf(data[i].url, PATH_MAX, "%s/%s/%s/%s", server_url,
+
+  loc = strstr(escaped_string, "%2F");
+  if (loc != NULL)
+while( (loc = strstr(loc, "%2F")) )
+  {
+loc[0] = '/';
+// pull the string back after replacement
+memmove(loc+1,loc+3,strlen(loc+3)+1);
+  } 
+  snprintf(data[i].url, PATH_MAX, "%s/%s/%s%s", server_url,
build_id_bytes, type, escaped_string);
   curl_free(escaped_string);
 }
-- 
2.31.1



Re: [PATCH] lib: remove usage of `sys/cdefs.h`

2021-08-27 Thread Mark Wielaard
Hi Saleem,

On Mon, 2021-08-23 at 08:23 -0700, Saleem Abdulrasool via Elfutils-
devel wrote:
> Yes, it seems that `STROF` can be removed as well.  However, I'd
> prefer to do that in a separate change.  This way the change is a
> separate clean up rather than just happens to come along with the
> sys/cdefs.h removal.

Please do post a followup patch.

I added a ChangeLog entry (yes, we still do those, although it seems
very little people share my enthusiasm for them, so maybe we should
drop them, at least as separate file entries) and pushed your patch as:

commit d390548df1942e98a1d836269a5e41ba52e121f1
Author: Saleem Abdulrasool 
Date:   Fri Aug 20 18:20:08 2021 +

lib: remove usage of `sys/cdefs.h`

This header is a BSD header that is also available in glibc.  However,
this is a not a standard C header and was used for `__CONCAT`.  Because
this is not a standard header, not all libc implementations provide the
header.  Remove the usage of the header and always use the previously
fallback path.  This is needed in order to build with musl.

Signed-off-by: Saleem Abdulrasool 

Thanks,

Mark

P.S. You might want to use git send-email --from=... to add an extra
>From author line. Sadly the mailinglist mangles the original From in
some cases causing git am to apply a patch with the mailinglist as
author (sorry about that).


Re: [PATCH] debuginfod, elfclassify: remove unnecessary header inclusion

2021-08-27 Thread Mark Wielaard
Hi Saleem,

On Fri, 2021-08-20 at 18:21 +, Saleem Abdulrasool via Elfutils-devel wrote:
> `error.h`'s inclusion was centralised into the `system.h` header.  As
> the implementation currently includes `system.h` already, the inclusion
> of `error.h` is unnecessary.  This prepares for a future portability
> change to allow elfutil to build with alternate libc implementations.
> 
> Signed-off-by: Saleem Abdulrasool 

Thanks. Added ChangeLog entries and pushed.

Cheers,

Mark


[PATCH] lib: remove unused `STROF` definition (NFC)

2021-08-27 Thread Saleem Abdulrasool via Elfutils-devel
This definition was in the fallback path, where `sys/cdefs.h` is not
available.  Now that we have a single path through here, this macro gets
defined, though is unused.  Remove the unused macro definition.

Signed-off-by: Saleem Abdulrasool 
---
 lib/ChangeLog   | 4 
 lib/fixedsizehash.h | 1 -
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/ChangeLog b/lib/ChangeLog
index a95f8041..5f1de1e2 100644
--- a/lib/ChangeLog
+++ b/lib/ChangeLog
@@ -1,3 +1,7 @@
+2021-08-21  Saleem Abdulrasool  
+
+   * fixedsizehash.h: Remove unused STROF macro.
+
 2021-08-20  Saleem Abdulrasool  
 
* fixedsizehash.h: Remove sys/cdefs.h include. Unconditionally
diff --git a/lib/fixedsizehash.h b/lib/fixedsizehash.h
index f333ad99..14f0fb88 100644
--- a/lib/fixedsizehash.h
+++ b/lib/fixedsizehash.h
@@ -33,7 +33,6 @@
 
 #include 
 
-#define STROF(t2) t2
 #define CONCAT_EXPANDED(t1,t2) t1 ## t2
 #define CONCAT(t1,t2) CONCAT_EXPANDED(t1,t2)
 
-- 
2.33.0.259.gc128427fd7-goog



Re: [PATCH v2] handle libc implemntations which do not provide `error.h`

2021-08-27 Thread Saleem Abdulrasool via Elfutils-devel
I think that this is not exactly ideal, as it will introduce a local
error_message_count in each translation unit, rather than giving it
vague linkage as I had hoped.  I think it may be better to introduce a new
source file here.  I can move the implementation around though.

A second issue is that playing with this further, it doesn't fully resolve
the PR as this only fixes it for libelf (which I realized only recently).

On Fri, Aug 20, 2021 at 1:28 PM Saleem Abdulrasool 
wrote:

> Introduce a configure time check for the presence of `error.h`.  In the
> case that `error.h` is not available, we can fall back to `err.h`.
> Although `err.h` is not a C standard header (it is a BSD extension),
> many libc implementations provide.  If there are targets which do not
> provide an implementation of `err.h`, it would be possible to further
> extend the implementation to be more portable.
>
> This resolves bug #21008.
>
> Signed-off-by: Saleem Abdulrasool 
> ---
>  configure.ac |  3 +++
>  lib/system.h | 26 +-
>  2 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 7caff2c5..177bb1a2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -431,6 +431,9 @@ AC_CHECK_DECLS([reallocarray],[],[],
>
>  AC_CHECK_FUNCS([process_vm_readv])
>
> +AC_CHECK_HEADERS([error.h])
> +AC_CHECK_HEADERS([err.h])
> +
>  old_CFLAGS="$CFLAGS"
>  CFLAGS="$CFLAGS -D_GNU_SOURCE"
>  AC_FUNC_STRERROR_R()
> diff --git a/lib/system.h b/lib/system.h
> index 58d9deee..b963fd15 100644
> --- a/lib/system.h
> +++ b/lib/system.h
> @@ -29,8 +29,9 @@
>  #ifndef LIB_SYSTEM_H
>  #define LIB_SYSTEM_H   1
>
> +#include 
> +
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -38,8 +39,31 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
> +#if defined(HAVE_ERROR_H)
> +#include 
> +#elif defined(HAVE_ERR_H)
> +#include 
> +
> +static int error_message_count = 0;
> +
> +static inline void error(int status, int errnum, const char *format, ...)
> {
> +  va_list argp;
> +
> +  va_start(argp, format);
> +  verr(status, format, argp);
> +  va_end(argp);
> +
> +  if (status)
> +exit(status);
> +  ++error_message_count;
> +}
> +#else
> +#error "err.h or error.h must be available"
> +#endif
> +
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
>  # define LE32(n)   (n)
>  # define LE64(n)   (n)
> --
> 2.33.0.rc2.250.ged5fa647cd-goog
>
>


Re: [Bug debuginfod/28034] client-side %-escape url characters

2021-08-27 Thread Noah Sanci via Elfutils-devel
Hello,

Next update, removed redundant if statement.

-Noah Sanci

On Fri, Aug 27, 2021 at 11:07 AM Noah Sanci  wrote:
>
> Hello
>
> Update 2, no longer append nulls unnecessarily.
>
> -Noah Sanci
>
> On Fri, Aug 27, 2021 at 10:44 AM Noah Sanci  wrote:
> >
> > Hello,
> >
> > Here is an updated patch, using memmove. Much smaller.
> >
> > Thanks for the suggestions,
> >
> > Noah Sanci
> >
> >
> > On Thu, Aug 26, 2021 at 5:02 PM Frank Ch. Eigler  wrote:
> > >
> > > Hi -
> > >
> > > >/* PR28034 escape characters in completed url to %hh format. 
> > > > */
> > > > -  char *escaped_string;
> > > > -  escaped_string = curl_easy_escape(data[i].handle, filename, 
> > > > 0);
> > > > -  if (!escaped_string)
> > > > +  char escaped_string[PATH_MAX] = {'\0'};
> > > > +  char *loc = (char *) filename;
> > > > +  char *loc2;
> > > > +  char *tmp;
> > > > +  for(size_t j = 0; j < strlen(filename); ++j)
> > > >  {
> > > > -  rc = -ENOMEM;
> > > > -  goto out2;
> > > > +  loc2 = strstr(loc, "/");
> > > > +  // If the first character is a '/'
> > > > [...]
> > >
> > > Holy cow that's a lot of work to do it this way.
> > > A couple of alternatives:
> > >
> > > - ditch curl_easy_escape :-( and use a
> > >   malloc(strlen(x)*3)
> > >   byte-by-byte copy from source string into destination
> > > if not [a-zA-Z0-9/.~] then %-escape
> > >
> > > or:
> > > - keep curl_easy_escape and postprocess
> > >   byte-by-byte examine the result of curl_easy_escape
> > >   - if seeing a "%2F", replace the % with a / and memmove the
> > > rest of the string 2 bytes ahead
> > >
> > > It shouldn't need strtok or strstr or a lot of logic or stuff like
> > > that really.
> > >
> > > - FChE
> > >
From a27c9a82546b040fbb8e5263003fd8fb33f1f1e0 Mon Sep 17 00:00:00 2001
From: Noah Sanci 
Date: Fri, 16 Jul 2021 15:16:20 -0400
Subject: [PATCH] debuginfod: PR28034 - client-side %-escape url characters

When requesting some source files, some URL-inconvenient chars
sometimes pop up.  Example from f33 libstdc++:
/buildid/44d8485cb75512c2ca5c8f70afbd475cae30af4f/source/usr/src/debug/
gcc-10.3.1-1.fc33.x86_64/obj-x86_64-redhat-linux/x86_64-redhat-linux/
libstdc++-v3/src/c++11/../../../../../libstdc++-v3/src/c++11/
condition_variable.cc
As this URL is passed into debuginfod's handler_cb, it appears that the
+ signs are helpfully unescaped to spaces by libmicrohttpd, which
'course breaks everything.
In order to ensure the server properly parses urls such as this one,
%-escape characters on the client side so that the correct url
is preserved and properly processed on the server side.

https://sourceware.org/bugzilla/show_bug.cgi?id=28034

Signed-off-by: Noah Sanci 
---
 debuginfod/debuginfod-client.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index 7d4b220f..73960424 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -906,12 +906,20 @@ debuginfod_query_server (debuginfod_client *c,
   /* PR28034 escape characters in completed url to %hh format. */
   char *escaped_string;
   escaped_string = curl_easy_escape(data[i].handle, filename, 0);
+  char *loc = escaped_string;
   if (!escaped_string)
 {
   rc = -ENOMEM;
   goto out2;
 }
-  snprintf(data[i].url, PATH_MAX, "%s/%s/%s/%s", server_url,
+
+  while( (loc = strstr(loc, "%2F")) )
+{
+loc[0] = '/';
+// pull the string back after replacement
+memmove(loc+1,loc+3,strlen(loc+3)+1);
+}
+  snprintf(data[i].url, PATH_MAX, "%s/%s/%s%s", server_url,
build_id_bytes, type, escaped_string);
   curl_free(escaped_string);
 }
-- 
2.31.1



[PATCH v3] handle libc implemntations which do not provide `error.h`

2021-08-27 Thread Saleem Abdulrasool via Elfutils-devel
Introduce a configure time check for the presence of `error.h`.  In the
case that `error.h` is not available, we can fall back to `err.h`.
Although `err.h` is not a C standard header (it is a BSD extension),
many libc implementations provide.  If there are targets which do not
provide an implementation of `err.h`, it would be possible to further
extend the implementation to be more portable.

This partially resolves bug #21008.

Signed-off-by: Saleem Abdulrasool 
---
 configure.ac|  3 +++
 lib/ChangeLog   |  7 +++
 lib/Makefile.am |  2 +-
 lib/error.c | 49 +
 lib/system.h| 13 -
 5 files changed, 72 insertions(+), 2 deletions(-)
 create mode 100644 lib/error.c

diff --git a/configure.ac b/configure.ac
index 7caff2c5..177bb1a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -431,6 +431,9 @@ AC_CHECK_DECLS([reallocarray],[],[],
 
 AC_CHECK_FUNCS([process_vm_readv])
 
+AC_CHECK_HEADERS([error.h])
+AC_CHECK_HEADERS([err.h])
+
 old_CFLAGS="$CFLAGS"
 CFLAGS="$CFLAGS -D_GNU_SOURCE"
 AC_FUNC_STRERROR_R()
diff --git a/lib/ChangeLog b/lib/ChangeLog
index a95f8041..101a4e6f 100644
--- a/lib/ChangeLog
+++ b/lib/ChangeLog
@@ -1,3 +1,10 @@
+2021-08-20  Saleem Abdulrasool  
+
+   * error.c: New file, adds error_number_count and error fallbacks.
+   * system.h: Declare error_number_count and error fallbacks for when
+   error.h is unavailable.
+   * Makefile.am (libeu_a_SOURCES): add error.c.
+
 2021-08-20  Saleem Abdulrasool  
 
* fixedsizehash.h: Remove sys/cdefs.h include. Unconditionally
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 97bf7329..766fbcd7 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -35,7 +35,7 @@ noinst_LIBRARIES = libeu.a
 
 libeu_a_SOURCES = xstrdup.c xstrndup.c xmalloc.c next_prime.c \
  crc32.c crc32_file.c \
- color.c printversion.c
+ color.c error.c printversion.c
 
 noinst_HEADERS = fixedsizehash.h libeu.h system.h dynamicsizehash.h list.h \
 eu-config.h color.h printversion.h bpf.h \
diff --git a/lib/error.c b/lib/error.c
new file mode 100644
index ..b0264efb
--- /dev/null
+++ b/lib/error.c
@@ -0,0 +1,49 @@
+/* Definitions for error handling fallback functions.
+   Copyright (C) 2021 Google, Inc.
+   This file is part of elfutils.
+
+   This file is free software; you can redistribute it and/or modify
+   it under the terms of either
+
+ * the GNU Lesser General Public License as published by the Free
+   Software Foundation; either version 3 of the License, or (at
+   your option) any later version
+
+   or
+
+ * the GNU General Public License as published by the Free
+   Software Foundation; either version 2 of the License, or (at
+   your option) any later version
+
+   or both in parallel, as here.
+
+   elfutils is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received copies of the GNU General Public License and
+   the GNU Lesser General Public License along with this program.  If
+   not, see .  */
+
+#include 
+
+#if !defined(HAVE_ERROR_H) && defined(HAVE_ERR_H)
+#include 
+#include 
+#include 
+
+unsigned int error_message_count = 0;
+
+void error(int status, int errnum, const char *format, ...) {
+  va_list argp;
+
+  va_start(argp, format);
+  verr(status, format, argp);
+  va_end(argp);
+
+  if (status)
+exit(status);
+  ++error_message_count;
+}
+#endif
diff --git a/lib/system.h b/lib/system.h
index 58d9deee..edbc8488 100644
--- a/lib/system.h
+++ b/lib/system.h
@@ -29,8 +29,9 @@
 #ifndef LIB_SYSTEM_H
 #define LIB_SYSTEM_H   1
 
+#include 
+
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -38,8 +39,18 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
+#if defined(HAVE_ERROR_H)
+#include 
+#elif defined(HAVE_ERR_H)
+extern int error_message_count;
+void error(int status, int errnum, const char *format, ...);
+#else
+#error "err.h or error.h must be available"
+#endif
+
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 # define LE32(n)   (n)
 # define LE64(n)   (n)
-- 
2.33.0.259.gc128427fd7-goog



Re: [PATCH v2] handle libc implemntations which do not provide `error.h`

2021-08-27 Thread Mark Wielaard
Hi Saleem,

On Fri, 2021-08-27 at 08:24 -0700, Saleem Abdulrasool via Elfutils-devel wrote:
> I think that this is not exactly ideal, as it will introduce a local
> error_message_count in each translation unit, rather than giving it
> vague linkage as I had hoped.  I think it may be better to introduce a new
> source file here.  I can move the implementation around though.
> 
> A second issue is that playing with this further, it doesn't fully resolve
> the PR as this only fixes it for libelf (which I realized only recently).

Oops. Our messages crossed and I just pushed:

commit 76c84c137a82a7cacbc69b1696052491b3bb81cb
Author: Saleem Abdulrasool 
Date:   Fri Aug 20 20:28:23 2021 +

handle libc implementations which do not provide `error.h`

Introduce a configure time check for the presence of `error.h`.  In the
case that `error.h` is not available, we can fall back to `err.h`.
Although `err.h` is not a C standard header (it is a BSD extension),
many libc implementations provide.  If there are targets which do not
provide an implementation of `err.h`, it would be possible to further
extend the implementation to be more portable.

This resolves bug #21008.

Signed-off-by: Saleem Abdulrasool 

It passes all local tests and it is currently going through the buildbot:
https://builder.wildebeest.org/buildbot/#/changes/2530
But of course all those systems use normal glibc.

Should I revert the commit?

Thanks,

Mark


Re: [PATCH v2] handle libc implemntations which do not provide `error.h`

2021-08-27 Thread Saleem Abdulrasool via Elfutils-devel
We have two choices:
- revert and use the updated patch I already sent
- I can do a follow up change to migrate the code

I don't particularly have a strong opinion on which approach we take, since
the commit has already been done.  Since glibc systems are completely
untouched by the changes neither path should cause problems for bisection
in the future for previously supported systems.  I'd go with whatever is
most commonly done in this project.

On Fri, Aug 27, 2021 at 8:39 AM Mark Wielaard  wrote:

> Hi Saleem,
>
> On Fri, 2021-08-27 at 08:24 -0700, Saleem Abdulrasool via Elfutils-devel
> wrote:
> > I think that this is not exactly ideal, as it will introduce a local
> > error_message_count in each translation unit, rather than giving it
> > vague linkage as I had hoped.  I think it may be better to introduce a
> new
> > source file here.  I can move the implementation around though.
> >
> > A second issue is that playing with this further, it doesn't fully
> resolve
> > the PR as this only fixes it for libelf (which I realized only recently).
>
> Oops. Our messages crossed and I just pushed:
>
> commit 76c84c137a82a7cacbc69b1696052491b3bb81cb
> Author: Saleem Abdulrasool 
> Date:   Fri Aug 20 20:28:23 2021 +
>
> handle libc implementations which do not provide `error.h`
>
> Introduce a configure time check for the presence of `error.h`.  In the
> case that `error.h` is not available, we can fall back to `err.h`.
> Although `err.h` is not a C standard header (it is a BSD extension),
> many libc implementations provide.  If there are targets which do not
> provide an implementation of `err.h`, it would be possible to further
> extend the implementation to be more portable.
>
> This resolves bug #21008.
>
> Signed-off-by: Saleem Abdulrasool 
>
> It passes all local tests and it is currently going through the buildbot:
> https://builder.wildebeest.org/buildbot/#/changes/2530
> But of course all those systems use normal glibc.
>
> Should I revert the commit?
>
> Thanks,
>
> Mark
>


[PATCH] lib: avoid potential problems with `-fno-common`

2021-08-27 Thread Saleem Abdulrasool via Elfutils-devel
This properly homes the fallback function into a translation unit rather
than trying to define an inline common definition for the fallback path.
The intent of the original approach was to actually simply avoid adding
a new source file that is used for the fallback path.  However, that may
cause trouble with multiple definitions if the symbol does not get vague
linkage (which itself is not particularly great).  This simplifies the
behaviour at the cost of an extra inode.
---
 lib/ChangeLog   |  9 +
 lib/Makefile.am |  2 +-
 lib/error.c | 49 +
 lib/system.h| 17 ++---
 4 files changed, 61 insertions(+), 16 deletions(-)
 create mode 100644 lib/error.c

diff --git a/lib/ChangeLog b/lib/ChangeLog
index 589953cf..c784b689 100644
--- a/lib/ChangeLog
+++ b/lib/ChangeLog
@@ -1,3 +1,12 @@
+2021-08-23  Saleem Abdulrasool  
+
+   * system.h: Remove inline definition for error and error_message_count
+   in the fallback path.
+   * Makefile.am (libeu_a_SOURCES): Add error.c.
+   * error.c: New file, moves the previous inline definitions to avoid
+   multiple definitions properly rather than relying on -fcommon and vague
+   linkage.
+
 2021-08-20  Saleem Abdulrasool  
 
* system.h: Check for HAVE_ERROR_H and HAVE_ERR_H and define
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 97bf7329..766fbcd7 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -35,7 +35,7 @@ noinst_LIBRARIES = libeu.a
 
 libeu_a_SOURCES = xstrdup.c xstrndup.c xmalloc.c next_prime.c \
  crc32.c crc32_file.c \
- color.c printversion.c
+ color.c error.c printversion.c
 
 noinst_HEADERS = fixedsizehash.h libeu.h system.h dynamicsizehash.h list.h \
 eu-config.h color.h printversion.h bpf.h \
diff --git a/lib/error.c b/lib/error.c
new file mode 100644
index ..75e964fd
--- /dev/null
+++ b/lib/error.c
@@ -0,0 +1,49 @@
+/* Definitions for error fallback functions.
+   Copyright (C) 2021 Google, Inc.
+   This file is part of elfutils.
+
+   This file is free software; you can redistribute it and/or modify
+   it under the terms of either
+
+ * the GNU Lesser General Public License as published by the Free
+   Software Foundation; either version 3 of the License, or (at
+   your option) any later version
+
+   or
+
+ * the GNU General Public License as published by the Free
+   Software Foundation; either version 2 of the License, or (at
+   your option) any later version
+
+   or both in parallel, as here.
+
+   elfutils is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received copies of the GNU General Public License and
+   the GNU Lesser General Public License along with this program.  If
+   not, see .  */
+
+#include 
+
+#if !defined(HAVE_ERROR_H) && defined(HAVE_ERR_H)
+#include 
+#include 
+#include 
+
+unsigned int error_message_count = 0;
+
+void error(int status, int errnum, const char *format, ...) {
+  va_list argp;
+
+  va_start(argp, format);
+  verr(status, format, argp);
+  va_end(argp);
+
+  if (status)
+exit(status);
+  ++error_message_count;
+}
+#endif
diff --git a/lib/system.h b/lib/system.h
index b963fd15..edbc8488 100644
--- a/lib/system.h
+++ b/lib/system.h
@@ -45,21 +45,8 @@
 #if defined(HAVE_ERROR_H)
 #include 
 #elif defined(HAVE_ERR_H)
-#include 
-
-static int error_message_count = 0;
-
-static inline void error(int status, int errnum, const char *format, ...) {
-  va_list argp;
-
-  va_start(argp, format);
-  verr(status, format, argp);
-  va_end(argp);
-
-  if (status)
-exit(status);
-  ++error_message_count;
-}
+extern int error_message_count;
+void error(int status, int errnum, const char *format, ...);
 #else
 #error "err.h or error.h must be available"
 #endif
-- 
2.33.0.259.gc128427fd7-goog



Re: [PATCH] lib: remove unused `STROF` definition (NFC)

2021-08-27 Thread Mark Wielaard
Hi Saleem,

On Fri, 2021-08-27 at 15:20 +, Saleem Abdulrasool via Elfutils-devel wrote:
> This definition was in the fallback path, where `sys/cdefs.h` is not
> available.  Now that we have a single path through here, this macro gets
> defined, though is unused.  Remove the unused macro definition.

The STROF macro is not used, so this is indeed a NFC.
Pushed.

Thanks,

Mark


Re: [PATCH] lib: avoid potential problems with `-fno-common`

2021-08-27 Thread Mark Wielaard
Hi Saleem,

On Fri, 2021-08-27 at 15:51 +, Saleem Abdulrasool via Elfutils-devel wrote:
> This properly homes the fallback function into a translation unit rather
> than trying to define an inline common definition for the fallback path.
> The intent of the original approach was to actually simply avoid adding
> a new source file that is used for the fallback path.  However, that may
> cause trouble with multiple definitions if the symbol does not get vague
> linkage (which itself is not particularly great).  This simplifies the
> behaviour at the cost of an extra inode.

I applied this, but messed up, sorry.
I somehow dropped the lib/error.c file from the commit.

When the buildbot yells and screams about a broken build that wasn't
your fault. I pushed a followup commit to fix it:

commit 610623458b7e98ed3e912e4b7ca8050f6ce4c698 (HEAD -> master)
Author: Mark Wielaard 
Date:   Fri Aug 27 18:47:30 2021 +0200

Add lib/error.c

This new file was supposed to be part of 4d6dd0e5a "lib: avoid potential
problems with `-fno-common`".

Signed-off-by: Mark Wielaard 

Apologies,

Mark


[Bug general/21008] Incompatible with MUSL libc: error.h and error() not provided

2021-08-27 Thread mark at klomp dot org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21008

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Mark Wielaard  ---
commit 76c84c137a82a7cacbc69b1696052491b3bb81cb
Author: Saleem Abdulrasool 
Date:   Fri Aug 20 20:28:23 2021 +

handle libc implementations which do not provide `error.h`

Introduce a configure time check for the presence of `error.h`.  In the
case that `error.h` is not available, we can fall back to `err.h`.
Although `err.h` is not a C standard header (it is a BSD extension),
many libc implementations provide.  If there are targets which do not
provide an implementation of `err.h`, it would be possible to further
extend the implementation to be more portable.

This resolves bug #21008.

Signed-off-by: Saleem Abdulrasool 

commit 4d6dd0e5ad5c3366cbf701b4fb62b6d91be545f8
Author: Saleem Abdulrasool 
Date:   Fri Aug 27 15:51:47 2021 +

lib: avoid potential problems with `-fno-common`

This properly homes the fallback function into a translation unit rather
than trying to define an inline common definition for the fallback path.
The intent of the original approach was to actually simply avoid adding
a new source file that is used for the fallback path.  However, that may
cause trouble with multiple definitions if the symbol does not get vague
linkage (which itself is not particularly great).  This simplifies the
behaviour at the cost of an extra inode.

commit 610623458b7e98ed3e912e4b7ca8050f6ce4c698
Author: Mark Wielaard 
Date:   Fri Aug 27 18:47:30 2021 +0200

Add lib/error.c

This new file was supposed to be part of 4d6dd0e5a "lib: avoid potential
problems with `-fno-common`".

Signed-off-by: Mark Wielaard 

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21002] Incompatible with MUSL libc

2021-08-27 Thread mark at klomp dot org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21002
Bug 21002 depends on bug 21008, which changed state.

Bug 21008 Summary: Incompatible with MUSL libc: error.h and error() not provided
https://sourceware.org/bugzilla/show_bug.cgi?id=21008

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [PATCH] debuginfod: PR27917 - protect against federation loops

2021-08-27 Thread Mark Wielaard
Hi dichen,

On Fri, 2021-08-20 at 20:44 +0800, Di Chen via Elfutils-devel wrote:
> 1) moved the XFF check to handle_buildid.
> 2) replace "livelock" with "deadlock" in the commit message.

This looks very good, thanks not just for the code but for also
including documentation and a testcase.

I did make one small change to the test:

diff --git a/tests/run-debuginfod-find.sh b/tests/run-debuginfod-find.sh
index dbf20975..7e12dd7f 100755
--- a/tests/run-debuginfod-find.sh
+++ b/tests/run-debuginfod-find.sh
@@ -819,6 +819,11 @@ while true; do
 ss -atn | fgrep -e ":$PORT4" -e ":$PORT5"|| break
 done
 
+# Make sure the vlogs are cleaned up after the test
+# and that they are printed on error.
+tempfiles vlog$PORT4 vlog$PORT5
+errfiles vlog$PORT4 vlog$PORT5
+
 env LD_LIBRARY_PATH=$ldpath DEBUGINFOD_URLS=http://127.0.0.1:$PORT5 
${abs_builddir}/../debuginfod/debuginfod $VERBOSE --forwarded-ttl-limit 0 -p 
$PORT4 > vlog$PORT4 2>&1 &
 PID5=$!

And added ChangeLog file entries. Then pushed.

Thanks,

Mark


[Bug debuginfod/27917] protect against federation loops

2021-08-27 Thread mark at klomp dot org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27917

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||mark at klomp dot org
 Status|NEW |RESOLVED

--- Comment #3 from Mark Wielaard  ---
commit d3f914023abcd6ae76b168da97518e5e7dbd761a
Author: Di Chen 
Date:   Fri Aug 20 13:03:21 2021 +0800

debuginfod: PR27917 - protect against federation loops

If someone misconfigures a debuginfod federation to have loops, and
a nonexistent buildid lookup is attempted, bad things will happen,
as is documented.

This patch aims to reduce the risk by adding an option to debuginfod
that functions kind of like an IP packet's TTL: a limit on the length of
XFF: header that debuginfod is willing to process. If X-Forwarded-For:
exceeds N hops, it will not delegate a local lookup miss to upstream
debuginfods.

Commit ab38d167c40c99 causes federation loops for non-existent resources
to result in multiple temporary deadlocks, each lasting for
$DEBUGINFOD_TIMEOUT seconds. Since concurrent requests for each unique
resource are now serialized, federation loops can result in one server
thread waiting to acquire a lock while the server thread holding the
lock waits for the first thread to respond to an http request.

This PR can help protect against the above multiple temporary deadlocks
behaviour. Ex. if --forwarded-ttl-limit=0 then the timeout behaviour of
local loops should be avoided.

https://sourceware.org/bugzilla/show_bug.cgi?id=27917

Signed-off-by: Di Chen 

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [Bug debuginfod/27277] Describe retrieved files when verbose

2021-08-27 Thread Noah Sanci via Elfutils-devel
Hello,

Here is the patch which prints the http headers when verbose.

-Noah Sanci

On Tue, Aug 24, 2021 at 4:19 AM Mark Wielaard  wrote:
>
> Hi Noah,
>
> On Mon, 2021-08-23 at 11:11 -0400, Noah Sanci wrote:
> > I'm back to working on this patch, thanks for your patience and
> > comments.
> >
> > On Mon, Aug 9, 2021 at 5:27 AM Mark Wielaard  wrote:
> > > Yes, separate the verbose printing of http headers (which I really do
> > > like) from providing an interface to query what needs to be done to get
> > > some file (is it in cache, can it be retieved from a remote server, how
> > > big is it?) I don't think providing raw http headers is that interface.
> >
> > Should I separate the verbose printing of http headers and the new
> > interface into
> > different PRs?
>
> Yes, separate bugs/patches for the two features would be ideal IMHO.
>
> Thanks,
>
> Mark
>
From ed7638571f188e346dd466c195b9ebda028d1c65 Mon Sep 17 00:00:00 2001
From: Noah Sanci 
Date: Wed, 28 Jul 2021 14:46:05 -0400
Subject: [PATCH] debuginfod: PR27277 - Describe retrieved files when verbose

There appear to exist use cases that intend to simply check for the
existence of content in a debuginfod server, without actually
downloading it.  In HTTP land, the HEAD operation is the natural
expression of this.
Instead of implementing a HEAD/describe option, allow users, with enough
verbosity, to print the HTTP response headers upon retrieving a file.
E.g output:

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 2428240
Cache-Control: public
Last-Modified: Sat, 15 May 2021 20:49:51 GMT
X-FILE: "file name"
X-FILE-SIZE: "byte length of file"
Content-Type: application/octet-stream
Date: Tue, 03 Aug 2021 18:50:36 GMT

https://sourceware.org/bugzilla/show_bug.cgi?id=27277

Signed-off-by: Noah Sanci 
---
 debuginfod/ChangeLog |  15 ++
 debuginfod/debuginfod-client.c   |  58 ++-
 debuginfod/debuginfod.cxx|  11 ++
 doc/ChangeLog|   7 +
 doc/debuginfod-find.1|   3 +-
 doc/debuginfod.8 |   7 +
 tests/ChangeLog  |   7 +
 tests/Makefile.am|   3 +-
 tests/run-debuginfod-response-headers.sh | 194 +++
 9 files changed, 299 insertions(+), 6 deletions(-)
 create mode 100755 tests/run-debuginfod-response-headers.sh

diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index 395af94f..d911d5b5 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -16,6 +16,21 @@
 	* debuginfod.cxx (handler_cb): Fix after_you unique_set key
 	to the entire incoming URL.
 
+2021-08-02  Noah Sanci  
+
+	PR27277
+	* debuginfod-client.c (struct debuginfod_client): New field
+	winning_headers.
+	(struct handle_data): New field response_data.
+	(header_callback): Store received headers in response_data.
+	(debuginfod_query_server): Activate CURLOPT_HEADERFUNCTION.
+	Save winning response_data.
+	(debuginfod_end): free client winning headers.
+	* debuginfod.cxx (handle_buildid_f_match): remove X-FILE path. Add
+	X-FILE and X-FILE-SIZE headers.
+	(handle_buildid_r_match): remove X-FILE path. Add X-FILE, X-FILE-SIZE
+	headers, and X-ARCHIVE headers.
+
 2021-07-26  Noah Sanci  
 
 	PR27982
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index 7d4b220f..eb52dddf 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -127,6 +127,7 @@ struct debuginfod_client
  timeout or other info gotten from environment variables, the
  handle data, etc. So those don't have to be reparsed and
  recreated on each request.  */
+  char * winning_headers;
 };
 
 /* The cache_clean_interval_s file within the debuginfod cache specifies
@@ -183,6 +184,8 @@ struct handle_data
  to the cache. Used to ensure that a file is not downloaded from
  multiple servers unnecessarily.  */
   CURL **target_handle;
+  /* Response http headers for this client handle, sent from the server */
+  char *response_data;
 };
 
 static size_t
@@ -499,6 +502,33 @@ default_progressfn (debuginfod_client *c, long a, long b)
 }
 
 
+static size_t
+header_callback (char * buffer, size_t size, size_t numitems, void * userdata)
+{
+  if (size != 1)
+return 0;
+  /* Temporary buffer for realloc */
+  char *temp = NULL;
+  size_t userlen = 0;
+  if (*(char**)userdata == NULL)
+{
+  temp = malloc(numitems+1);
+  if (temp == NULL)
+return 0;
+  memset(temp, '\0', numitems+1);
+}
+  else
+{
+  userlen = strlen(*(char**)userdata);
+  temp = realloc(*(char**)userdata, userlen + numitems + 1);
+  if (temp == NULL)
+   return 0;
+}
+  strncat(temp, buffer, numitems);
+  *(char**)userdata = temp;
+  return numitems;
+}
+
 /* Query each of the server URLs found in $DEBUGINFOD_URLS for the file
with the specified build-id, type (debuginfo, executable or source)
and filename. filename may be NULL. If found, return a f

[Bug debuginfod/28284] New: support description functionality through HEAD

2021-08-27 Thread nsanci at redhat dot com via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28284

Bug ID: 28284
   Summary: support description functionality through HEAD
   Product: elfutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: debuginfod
  Assignee: unassigned at sourceware dot org
  Reporter: nsanci at redhat dot com
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

Currently, checking the existence of a file and gathering its information
requires a user to download the file. This can be inconvenient for some users
who, for example, are curious to know information on a file before its
downloaded. Queries should be supported which allow a user to analyze some
information relating to a file without downloading it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/28284] support description functionality through HEAD

2021-08-27 Thread nsanci at redhat dot com via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28284

Noah Sanci  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |nsanci at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/28284] support description functionality through HEAD

2021-08-27 Thread fche at redhat dot com via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28284

Frank Ch. Eigler  changed:

   What|Removed |Added

 CC||fche at redhat dot com

--- Comment #1 from Frank Ch. Eigler  ---
The tricky aspect of this is not so much the webapi, but the C api and the
debuginfod-find cli.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Buildbot failure in Wildebeest Builder on whole buildset

2021-08-27 Thread buildbot
The Buildbot has detected a new failure on builder elfutils-centos-x86_64 while 
building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/1/builds/807

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: centos-x86_64

Build Reason: 
Blamelist: Saleem Abdulrasool 

BUILD FAILED: failed compile (failure)

Sincerely,
 -The BuildbotThe Buildbot has detected a new failure on builder 
elfutils-debian-amd64 while building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/2/builds/801

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: debian-amd64

Build Reason: 
Blamelist: Saleem Abdulrasool 

BUILD FAILED: failed compile (failure)

Sincerely,
 -The BuildbotThe Buildbot has detected a new failure on builder 
elfutils-fedora-x86_64 while building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/3/builds/805

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: fedora-x86_64

Build Reason: 
Blamelist: Saleem Abdulrasool 

BUILD FAILED: failed compile (failure)

Sincerely,
 -The BuildbotThe Buildbot has detected a new failure on builder 
elfutils-debian-i386 while building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/4/builds/801

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: debian-i386

Build Reason: 
Blamelist: Saleem Abdulrasool 

BUILD FAILED: failed compile (failure)

Sincerely,
 -The BuildbotThe Buildbot has detected a new failure on builder 
elfutils-fedora-s390x while building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/10/builds/771

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: fedora-s390x

Build Reason: 
Blamelist: Saleem Abdulrasool 

BUILD FAILED: failed compile (failure)

Sincerely,
 -The BuildbotThe Buildbot has detected a new failure on builder 
elfutils-fedora-ppc64le while building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/11/builds/756

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: fedora-ppc64le

Build Reason: 
Blamelist: Saleem Abdulrasool 

BUILD FAILED: failed compile (failure)

Sincerely,
 -The BuildbotThe Buildbot has detected a new failure on builder 
elfutils-fedora-ppc64 while building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/12/builds/754

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: fedora-ppc64

Build Reason: 
Blamelist: Saleem Abdulrasool 

BUILD FAILED: failed compile (failure)

Sincerely,
 -The BuildbotThe Buildbot has detected a new failure on builder 
elfutils-debian-armhf while building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/15/builds/596

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: debian-armhf

Build Reason: 
Blamelist: Saleem Abdulrasool 

BUILD FAILED: failed compile (failure)

Sincerely,
 -The BuildbotThe Buildbot has detected a new failure on builder 
elfutils-debian-arm64 while building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/45/builds/237

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: debian-arm64

Build Reason: 
Blamelist: Saleem Abdulrasool 

BUILD FAILED: failed compile (failure)

Sincerely,
 -The Buildbot



Buildbot failure in Wildebeest Builder on whole buildset

2021-08-27 Thread buildbot
The Buildbot has detected a new failure on builder elfutils-debian-amd64 while 
building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/2/builds/803

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: debian-amd64

Build Reason: 
Blamelist: Di Chen 

BUILD FAILED: failed test (failure)

Sincerely,
 -The BuildbotThe Buildbot has detected a new failure on builder 
elfutils-fedora-x86_64 while building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/3/builds/807

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: fedora-x86_64

Build Reason: 
Blamelist: Di Chen 

BUILD FAILED: failed test (failure)

Sincerely,
 -The BuildbotThe Buildbot has detected a new failure on builder 
elfutils-debian-arm64 while building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/45/builds/239

Buildbot URL: https://builder.wildebeest.org/buildbot/

Worker for this Build: debian-arm64

Build Reason: 
Blamelist: Di Chen 

BUILD FAILED: failed test (failure)

Sincerely,
 -The Buildbot