Re: [Bug debuginfod/28034] client-side %-escape url characters
Hi Noah, On Mon, 2021-09-13 at 14:11 -0400, Noah Sanci via Elfutils-devel wrote: > Quick arithmetic change to the original patch with an updated commit > message. Thanks for commenting this, it is easy to make an off-by-one (or two) error. > Previously, urls containing '/', so most urls, would escape '/' to %2F, > which is undesirable for use in other libraries which may escape > differently. This patch escapes the '/' and replaces all of them > ensuring there are no %2Fs sent. > Some inefficiencies within the code were fixed, such as changing constant > operations of a while loop within a for loop to a while loop outside of > a for loop. Also strlen is no longer used within the loop, simplifying > the interior operations to mere arithmetic. > > https://sourceware.org/bugzilla/show_bug.cgi?id=28034 Looks good. Could you push it to the master branch? (Please do rebase first, so we keep a linear history) Thanks, Mark
Re: [Bug debuginfod/27277] Describe retrieved files when verbose
Hi Noah,
On Mon, 2021-09-13 at 16:07 -0400, Noah Sanci via Elfutils-devel wrote:
> On Sun, Sep 12, 2021 at 3:08 PM Mark Wielaard wrote:
> > > run-debuginfod-fd-prefetch-caches.sh was updated so that it doesn't
> > > trip and fail as previously greping for a value that should yield zero
> > > caused an error.
> >
> > I think this part should be in this patch.
>
> Do you mean should or shouldn't? Removed for now.
That should should have been shouldn't.
> > > +# Wait till both files are in the index and scan/index fully
> > > finished
> > > +wait_ready $PORT1 'thread_work_total{role="traverse"}' 2
> > > +wait_ready $PORT1 'thread_work_pending{role="scan"}' 0
> > > +wait_ready $PORT1 'thread_busy{role="scan"}' 0
> > > +# All rpms need to be in the index, except the dummy permission-
> > > 000 one
> > > +rpms=$(find R -name \*rpm | grep -v nothing | wc -l)
> > > +wait_ready $PORT1 'scanned_files_total{source=".rpm archive"}'
> > > $rpms
> > > +kill -USR1 $PID1 # two hits of SIGUSR1 may be needed to resolve
> > > .debug->dwz->srefs
> > > +# Wait till both files are in the index and scan/index fully
> > > finished
> > > +wait_ready $PORT1 'thread_work_total{role="traverse"}' 3
> > > +wait_ready $PORT1 'thread_work_pending{role="scan"}' 0
> > > +wait_ready $PORT1 'thread_busy{role="scan"}' 0
> >
> > Is it really necessary to add all this if this is just a test to
> > check
> > the new headers are sent?
>
> A lot of the setup is to check that both the archive and regular file
> headers are added. In the attached
> path I removed as much as I felt reasonable. Please get back to me on
> if it is enough.
Ah, yes, of course I had forgotten about the archive headers.
> Subject: [PATCH] debuginfod: PR27277 - Describe retrieved files when verbose
>
> Allow users, with enough verbosity, to print the HTTP response headers
> upon retrieving a file. These files may include several custome http
> response headers such as X-DEBUGINFOD-FILE, X-DEBUGINFOD-SIZE, and
> X-DEBUGINFOD-ARCHIVE. These headers are added from the daemon, in
> debuginfod.cxx.
> run-debuginfod-fd-prefetch-caches.sh was updated so that it doesn't
> trip and fail as previously greping for a value that should yield zero
> caused an error.
^ This paragraph doesn't document a change in the patch.
> E.g output:
>
> HTTP/1.1 200 OK
> Connection: Keep-Alive
> Content-Length: 4095072
> Cache-Control: public
> Last-Modified: Thu, 09 Sep 2021 19:06:40 GMT
> X-FILE: debuginfod
> X-FILE-SIZE: 4095072
> Content-Type: application/octet-stream
> Date: Fri, 10 Sep 2021 16:38:06 GMT
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=27277
But except for that one paragraph in the commit message that shouldn't
be there, this looks good. Please remove that paragraph from the commit
message (or replace it with one describing the new test added), rebase
it against the master branch and push it please.
Thanks,
Mark
Buildbot failure in Wildebeest Builder on whole buildset
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/839 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: centos-x86_64 Build Reason: Blamelist: Noah Sanci BUILD FAILED: failed test (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/798 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: Blamelist: Noah Sanci BUILD FAILED: failed test (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/623 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-armhf Build Reason: Blamelist: Noah Sanci 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/264 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-arm64 Build Reason: Blamelist: Noah Sanci BUILD FAILED: failed test (failure) Sincerely, -The Buildbot
Re: Buildbot failure in Wildebeest Builder on whole buildset
Hi, On Thu, 2021-09-16 at 15:00 +, build...@builder.wildebeest.org wrote: > 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/839 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: centos-x86_64 > > Build Reason: > Blamelist: Noah Sanci > > BUILD FAILED: failed test (failure) So it looks like half of the buildbot workers got a failure on the new run-debuginfod-response-headers.sh testcase grepping for Content-Length in the vlog-find$PORT1.1 output file from the debuginfod-find test. See https://builder.wildebeest.org/buildbot/#/changes/2659 I don't immediately know what they have in common. My first thought was that it might depend on the libmicrohttpd version? But it seems the failing workers are both new and old distros (centos, debian and fedora). Noah, could you take a look to see what/why the testcase might be failing? Thanks, Mark > 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/798 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: fedora-s390x > > Build Reason: > Blamelist: Noah Sanci > > BUILD FAILED: failed test (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/623 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: debian-armhf > > Build Reason: > Blamelist: Noah Sanci > > 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/264 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: debian-arm64 > > Build Reason: > Blamelist: Noah Sanci > > BUILD FAILED: failed test (failure) > > Sincerely, > -The Buildbot >
[Bug general/24964] elfutils fails to configure/build on CC=clang: configure: error: gcc with GNU99 support required
https://sourceware.org/bugzilla/show_bug.cgi?id=24964 --- Comment #4 from Adrian Ratiu --- FYI: This should be fixed now in latest dev branch. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24964] elfutils fails to configure/build on CC=clang: configure: error: gcc with GNU99 support required
https://sourceware.org/bugzilla/show_bug.cgi?id=24964
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Mark Wielaard ---
commit 6eb991a9ebc45cc468a049ef30a98a0f7cad4a0d
Author: Adrian Ratiu
Date: Mon Aug 30 18:43:13 2021 +0300
configure.ac: rework gnu99 ext check to allow clang
It is true that Clang does not support all gnu99 extensions [1],
but not all of them are used in the codebase and over time there
have been code cleanup efforts to improve Clang support.
For example after commit 779c57ea ("readelf: Pull advance_pc()
in file scope") there are no more nested function declarations
and elfutils now builds fine with Clang.
So in the interest of enabling Clang builds we remove the only
remaining blocker: the configure checks for nested functions and
variable length arrays which are also unused.
Considering mixed decls and code is also part of c99 standard,
the entire check becomes redundant and we can just replace
AC_PROG_CC -> AC_PROG_CC_C99.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=24964
Signed-off-by: Adrian Ratiu
--
You are receiving this mail because:
You are on the CC list for the bug.
