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
> > > comp
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 sou
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
> > prefix
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
d
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, --
On Thu, 2019-11-21 at 15:16 +0100, Mark Wielaard wrote:
> 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
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 you
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
> > th
