Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 8, 2021 at 2:06 PM David Cantrell <dcantrell@xxxxxxxxxx> wrote:
>
> On Thu, Oct 28, 2021 at 09:30:18PM +0200, Lennart Poettering wrote:
> >On Do, 28.10.21 12:10, David Cantrell (dcantrell@xxxxxxxxxx) wrote:
> >
> >> Thanks for revising the change proposal and filling in more details.
> >> After reading through it, I have some questions:
> >>
> >> 1) The proposal notes that users tend to combine built packages from
> >> different distributions.  Even in the current environment, do we care
> >> about those use cases without also getting a reproducer for Fedora?
> >
> >I'd see it this way: ultimately, if this gets adopted by multiple
> >distros this annotation will helps us separating out the reports by
> >distro, and then ignore everything but fedora. i.e. if someone deploys
> >a debian or ubuntu container on a fedora host this should be something
> >we shouldn't be bothered with supporting. But right now a coredump
> >generated that way won't tell us much about the situation. But once
> >this spec is adopted this becomes easy: if we get a report we'll
> >immediately see that the code that aborted was actually from a
> >different distro, and we can point the reporter to that and tell them
> >politely to ask the other distro for help, or alternatively invest the
> >time and reproduce the issue with the binary provided by fedora
> >instead.
> >
> >So, having this info around us allows us to be more efficient with
> >"not caring" for non-fedora issues.
> >
> >> For me, I feel that in a situation like that where a user has
> >> submitted a bug report that implies using a binary from some other
> >> distribution will lead me to ask "ok, but does this happen with the
> >> packages provided in Fedora?  If so, how can I reproduce the problem
> >> locally?"  So while these scenarios are described in the proposal, are
> >> they something that Fedora is trying to support?
> >
> >Well, I don't think Fedora has to care about crashes in other distro's
> >binaries. we have more than enough to look after anyway. But I do think
> >we should make it easier to detect this situation and more easily
> >provide helpful pointers how to find someone else who might be
> >interested or what to do to make fedora interested.
> >
> >> 3) The proposal notes making crash reporting more user-readable.  NVRs
> >> instead of Build-IDs, for instance.  Why can't systemd ask debuginfod
> >> for that information for reporting?  Why does this need to be embedded
> >> in the ELF objects?  If it's a value-add, then it could happen if
> >> debuginfod is set up and just have it fall back on the current
> >> reporting mechanism.
> >
> >We want to be able to do things generically in an offline fashion in
> >systemd-coredump. I.e. we run the coredump analyzer in a tight
> >sandbox, and we want quick answers without relying on the network.
> >
> >The goal of systemd-coredump is to make a coredump something that is
> >primarily a relatively cheapish log event, and were we do analysis as
> >much as possible locally, automatically, securely, in privacy and
> >quickly. If we'd always talk to the network we'd have to open our
> >sandbox quite a bit, we'd be dependent on external services, we'd leak
> >some data to the outside, we'd be unreliable and slower — and all that
> >even though we are interested in only a single string of data
> >ultimately.
> >
> >(I think debuginfod is excellent, but I think it would probably be a
> >consumer of this spec, not a replacement. for example, consider that
> >the spec has a suggested field 'debugInfoUrl' already, which would
> >inform debugging tools about the debuginfod servers to talk to to
> >acquire extended debug info data)
>
> I was thinking more about this proposal over the past weekend and
> where I keep ending up is that this is really optimizing for a small
> use case by touching ELF metadata all over the system.  And that
> strikes me as pretty invasive, so is it worth the tradeoffs and risks
> and such?
>
> Debugging is a pain, and anything to make that easier is better.  It
> has been stated multiple times that the information needs to be in the
> ELF header because containers and images may lack an RPM database.
> Fair, but what about the users that both want a container and image
> without the RPM database and systemd-coredump?  They still have all of
> their ELF files with this information that they removed in other ways.
> Do we provide those users with a script to strip .gnu.notes from
> everything or is that even a use case of concern?
>
> Efforts to get the system very small for container and image use has
> been a goal for a while.  And sure we're not talking about a lot of
> data, but that's now.  The size of everything only grows, so is that
> something to consider with the implementation of this feature?
>
> Another thing I thought about were reproducible builds.  Does this
> impact reproducible builds and if so, how do we handle that?
>
> I would feel more comfortable with this proposal if the data for
> systemd-coredump was not part of the ELF metadata.  Or if it
> absolutely must be part of the ELF metadata, users should know how it
> can be removed.  I would also vote for a format other than JSON, but
> that's just me.

Last cycle, I brought up the problem that it being part of the ELF
data destroys a lot of the value of the RPMCoW change[1] that is also
in development for this release. I'm disappointed that the Change
authors didn't care to resolve that issue for this iteration.

[1]: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/4Z652ASFD4ZYF3HUWO2KPLVSZDGUDFJH/




-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux