Hi,
On Thu, 2019-11-21 at 21:41 +0100, Mark Wielaard wrote:
> I think what makes the discussion somewhat difficult is that there are
> basically three cases:
>
> - Serving trees of rpms where only the contents of the rpms is shared.
> - Serving of a build directory where it makes sense to share n
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
Hi -
> I am simply interested in knowing what is done for outgoing https
> connections to be authenticated. What would it take to use the trust
> roots for validating the server certificates?
OK, I misunderstood. Certificate-authority certificates in the trust
root (compiled-in directories) serv
On Tue, 2019-11-19 at 16:15 -0500, Frank Ch. Eigler wrote:
> Hi -
>
>
> > [...] What I want is simply make it easy for the user to say where
> > they expect the sources are. So there is no surprises.
>
> If this were a mandate, it would be a hassle, for any build that's
> more than one directory
Hi -
> [...] What I want is simply make it easy for the user to say where
> they expect the sources are. So there is no surprises.
If this were a mandate, it would be a hassle, for any build that's
more than one directory wide.
> > The -F mode is suitable for sharing build trees. By definitio
Hi Frank,
On Tue, Nov 19, 2019 at 11:13:48AM -0500, Frank Ch. Eigler wrote:
> > > > This does keep me slightly worried. Even "trustworthy binaries" could
> > > > be produced by buggy compilers.
> > >
> > > Those would be untrustworthy binaries.
> > But then every binary could be untrustworthy :)
Hi -
> > > This does keep me slightly worried. Even "trustworthy binaries" could
> > > be produced by buggy compilers.
> >
> > Those would be untrustworthy binaries.
> But then every binary could be untrustworthy :)
If we have legitimate concerns about the correctness of toolchains
that the bui
Hi,
On Mon, 2019-11-18 at 13:41 -0500, Frank Ch. Eigler wrote:
> > > I see where you're going with it, it's a reasonable concern. For now,
> > > we can consider it covered by the "debuginfod should be given
> > > trustworthy binaries" general rule.
> >
> > This does keep me slightly worried. Eve
Hi -
> > I see where you're going with it, it's a reasonable concern. For now,
> > we can consider it covered by the "debuginfod should be given
> > trustworthy binaries" general rule.
>
> This does keep me slightly worried. Even "trustworthy binaries" could
> be produced by buggy compilers.
T
Hi -
> Now that we have the metrics maybe we can poll those to see if the new
> files have been indexed?
Sort of indirectly. But then we're back to polling, which itself
needs a timeout, so the logic is made at least as complicated.
> The reason I am complaining about this, is that make check
Hi,
On Fri, 2019-11-15 at 14:54 -0500, Frank Ch. Eigler wrote:
> > > +set -x
> >
> > Is this really necessary?
> > It makes the log files very verbose.
> > Or is that the intention?
>
> I've found it tricky to debug failing tests without this.
OK, but note that you can place echo "starting phas
Hi Frank,
On Fri, 2019-11-15 at 16:00 -0500, Frank Ch. Eigler wrote:
> > > + string popen_cmd = string("/usr/bin/rpm2cpio " +
> > > shell_escape(b_source0));
> >
> > Why the hardcoded path?
> > Could you check at startup if rpm2cpio is in the PATH?
>
> Hm, since this is run under popen(), so it
Hi,
On Thu, 2019-11-14 at 07:29 -0500, Frank Ch. Eigler wrote:
> > > -bin_PROGRAMS = debuginfod-find
> > > +bin_PROGRAMS = debuginfod debuginfod-find
> > > +debuginfod_SOURCES = debuginfod.cxx
> > > +debuginfod_cxx_CXXFLAGS = -Wno-unused-functions
> >
> > Should that be debuginfod_CXXFLAGS?
> > W
Hi Frank,
On Thu, 2019-11-14 at 06:54 -0500, Frank Ch. Eigler wrote:
> > > +++ b/config/debuginfod.sysconfig
> > > +#DEBUGINFOD_VERBOSE="-v"
> > > +DEBUGINFOD_PATHS="/usr/lib/debug /usr/bin /usr/sbin /usr/lib /usr/lib64
> > > /usr/local"
> >
> > Should this also include /usr/libexec ?
> > Isn't
Hi -
> > +// Roll this identifier for every sqlite schema incompatiblity.
> > +#define BUILDIDS "buildids9"
> > +
> > +#if SQLITE_VERSION_NUMBER >= 3008000
> > +#define WITHOUT_ROWID "without rowid"
> > +#else
> > +#define WITHOUT_ROWID ""
> > +#endif
> > +
> > +static const char DEBUGINFOD_SQLITE
Hi -
> And I don't like the pretty big testfiles, which aren't self-contained.
> You have to fetch them from a remote koji server. It would be much
> better to have a (small) self-contained .spec file that can be used to
> generate the rpms. Frank is already working on that.
Well, one did not h
Hi,
On Mon, 2019-10-28 at 15:07 -0400, Frank Ch. Eigler wrote:
> Subject: [PATCH 2/2] debuginfod 2/2: server side
>
> Add the server to the debuginfod/ subdirectory. This is a highly
> multithreaded c++11 program (still buildable on rhel7's gcc 4.8,
> which is only partly c++11 compliant). Incl
On Thu, 2019-11-14 at 21:44 +0100, Mark Wielaard wrote:
> > + // validate buildid
> > + if ((buildid.size() < 2) || // not empty
> > + (buildid.size() % 2) || // even number
> > + (buildid.find_first_not_of("0123456789abcdef") !=
> > string::npos)) // pure tasty lowercase hex
> > +t
Hi,
On Mon, 2019-10-28 at 15:07 -0400, Frank Ch. Eigler wrote:
> Add the server to the debuginfod/ subdirectory. This is a highly
> multithreaded c++11 program (still buildable on rhel7's gcc 4.8,
> which is only partly c++11 compliant). Includes an initial suite
> of tests, man pages, and a sam
Hi -
> Like with the client manpages, I think they should go into the doc/ dir
> just because all manpages are there at the moment.
OK.
> > -bin_PROGRAMS = debuginfod-find
> > +bin_PROGRAMS = debuginfod debuginfod-find
> > +debuginfod_SOURCES = debuginfod.cxx
> > +debuginfod_cxx_CXXFLAGS = -Wno-
Hi -
> > +++ b/config/debuginfod.service
> > +[Service]
> > +Group=debuginfod
> > +#CacheDirectory=debuginfod
> > +ExecStart=/usr/bin/debuginfod -d /var/cache/debuginfod/debuginfod.sqlite
> > -p $DEBUGINFOD_PORT $DEBUGINFOD_VERBOSE $DEBUGINFOD_PATHS
> Why is CacheDirectory commented out, I canno
On Mon, 2019-10-28 at 15:07 -0400, Frank Ch. Eigler wrote:
> Add the server to the debuginfod/ subdirectory. This is a highly
> multithreaded c++11 program (still buildable on rhel7's gcc 4.8,
> which is only partly c++11 compliant). Includes an initial suite
> of tests, man pages, and a sample s
Hi,
On Mon, 2019-10-28 at 15:07 -0400, Frank Ch. Eigler wrote:
> Add the server to the debuginfod/ subdirectory. This is a highly
> multithreaded c++11 program (still buildable on rhel7's gcc 4.8,
> which is only partly c++11 compliant). Includes an initial suite
> of tests, man pages, and a sam
29 matches
Mail list logo
