rfc/patch: user-agent distro-description for debuginfod http traffic

Mark Wielaard mark@klomp.org
Wed Jan 8 19:36:00 GMT 2020

Hi Frank,

On Wed, Jan 08, 2020 at 10:11:25AM -0500, Frank Ch. Eigler wrote:
> > Eep. We really should pick up this info during runtime instead of
> > during build time. 
> That's what I thought at first too.  However, doing it at run time
> means doing work - a popen() etc. - over and over or saving in a
> locked global.  Since on a normal machine, the distro doesn't change
> without elfutils also changing, it's practically a literal.

We are already opening some files to scan for cached files, open a
socket, download data, etc. I don't think one or two extra syscalls
are that much overhead.

> > We do want a reproducible build. 
> Can you give an example?  Bootstrapping a new distro version/arch?

Probably best explained at https://reproducible-builds.org/ most
distributions are participating.

> > And this will most likely produce wrong information if the package
> > build server is on a different OS or release than the OS/release it
> > is producing packages for. uname -sm might be "stable", but probably
> > not when cross- compiling.
> I wonder if the cross-compiled debuginfod-client case is worth
> worrying about.

I think it is.

> > But where does lsb_release come from? I don't have that on my
> > systems.
> BuildRequires: /usr/bin/lsb_release :-) It's a different package on
> different distros.  And running at run time would make a Require:
> rather than a one-time BuildRequire:.

It looks like the new standard (since about 8 years) is os-release:

It looks like an easily parsable file format.  The attached produces
some reasonable looking identification strings on a couple of my
systems out of the box:

Linux/i686 4.19.0-6-686-pae

Linux/x86_64 3.10.0-1062.9.1.el7.x86_64

Linux/x86_64 4.19.0-5-amd64

Maybe something like that is usable?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: os.c
Type: text/x-csrc
Size: 1171 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/elfutils-devel/attachments/20200108/b4f23a53/attachment.bin>

More information about the Elfutils-devel mailing list