Re: patch 2/2 debuginfod server etc.

2019-11-21 Thread Mark Wielaard
Hi Frank, On Thu, 2019-11-21 at 12:18 -0500, Frank Ch. Eigler wrote: > If the perceived problem is that build tree scans (-F) may > > > contain > > > binaries that refer to source files that are not appropriate for > > > later sharing, then IMO this is too much change, and unnecessarily > > >

Re: patch 2/2 debuginfod server etc.

2019-11-21 Thread Frank Ch. Eigler
Hi - > > If the perceived problem is that build tree scans (-F) may contain > > binaries that refer to source files that are not appropriate for > > later sharing, then IMO this is too much change, and unnecessarily > > complicates other valid usage. > > Yes, that (and references to any other

Re: patch 2/2 debuginfod server etc.

2019-11-21 Thread Mark Wielaard
Hi Frank, On Thu, 2019-11-21 at 10:57 -0500, Frank Ch. Eigler wrote: > > It simply splits the paths into those scanned for rpms, those scanned > > for files and (optional) paths that are extra trusted prefixes for > > source files. The paths that are scanned for files are trusted source > >

Re: patch 2/2 debuginfod server etc.

2019-11-21 Thread Frank Ch. Eigler
Hi - > On irc you mentioned that you didn't like that -R and -F didn't take > wildcards. The attached makes it so that they now do (you do have to > escape them or put them in single quotes, so the shell doesn't expand > them first). I stopped using -R PATH and -F PATH because it was clear that

Re: patch 2/2 debuginfod server etc.

2019-11-21 Thread Frank Ch. Eigler
Hi - > It simply splits the paths into those scanned for rpms, those scanned > for files and (optional) paths that are extra trusted prefixes for > source files. The paths that are scanned for files are trusted source > prefixes by default. There is a new option to also remove those using > -N,

Re: patch 2/2 debuginfod server etc.

2019-11-21 Thread Mark Wielaard
Hi, On Wed, 2019-11-20 at 12:53 +0100, Mark Wielaard wrote: > Sure, you could use that if you wanted to share your whole build/source > trees and don't mind serving any other files on some local network. I > just think it shouldn't be the default. If you go look for odd paths in > .debug files

Re: patch 1/2 debuginfod client

2019-11-21 Thread Mark Wielaard
On Wed, 2019-11-20 at 08:29 -0500, Frank Ch. Eigler wrote: > Hi - > > > But it isn't just about interference with other libcurl activity. > > If > > you look at the curl_global_init code you see that it actually > > calls > > a lot of code in other libraries. It is the curl_global_init code > >