On Thu, Oct 28, 2021 at 2:40 PM Luca Boccassi <bluca@xxxxxxxxxx> wrote: > > > On Mon, Oct 25, 2021 at 07:26:47PM +0000, Zbigniew Jędrzejewski-Szmek 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? > > 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? > > There are and there will be some who do care, and whose life will be made oh so much easier. Maybe they will be Fedora developers, or maybe they will be just Fedora users. Maybe it's someone managing a bunch of containers, and one of them happens to be Fedora, so it won't be you receiving the bug report, but someone else. We are trying to enable a cross distro specification, and this is part of building a solid base upon which others can build on. That should be enough already, no? > > > 2) The proposal is built around using the package NVR to indicate > > where it came from. But those names aren't unique. In some cases > > it'll work, but in cases where the noted package cannot be found or > > has been reaped or is just otherwise unavailable, you're back to > > asking for a reproducer on a Fedora release, right? Does the NVR data > > save much work over having build-ID plus debuginfod? That's not > > rhetorical? I don't have many bug reports that are not resolvable by > > just talking through a reproducer and seeing it happen locally, but I > > know I'm not a control case. > > Isn't the combination of distro name + distro version + package name + package version + package arch enough to uniquely identify? Are there cases where there can be duplicates in Fedora? Speaking of the Debian case, the distro version isn't even needed, you won't have duplicates even across multiple releases. > It is not enough. It's not enough in *any* distribution, because people can (re)build and deploy the same NEVRA. You *need* a build-id to guarantee uniqueness of the binary. If the NVR is the same but the build has been modified, the build-id changes. Debian has the same problem, especially when someone uses an Ubuntu package on Debian or vice-versa. NEVRAs are *not* globally unique. > > 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. > > First of all, we do not want to do network accesses from systemd-coredump, and keep any other system accesses to the bare minimum possible. It runs sandboxed, because core files are fundamentally unknown untrusted data, so the process doing that is restricted as much as possible. > > Secondly, internet access might be forbidden in the setup where a problem is happening. > > Thirdly, maybe it's the components that allow you to do network access in the first place that are crashing, and all you have is a serial console and desperation. > I think you've already failed at that. This would not help solve that problem, only guarantee that you need to. > Finally, as Mark said, with this scheme you can actually enable what you propose for the cases where it's possible, because as part of the metadata file you can include the debuginfod URL. Please think bigger picture than single distro: maybe the entity that created the binary uses the federated service so the build-id is enough, but maybe it does not. > > Fedora can be a trailblazer as always and be one of the first adopters (although CBL-Mariner beat you folks for first place :-) ) but our desired goal is very much to have this enabled cross-distro, so that a Fedora container on a Debian host or whatnot still works out of the box. Even if we did this, it will be a long, long, long time before there will be interop between Fedora and Debian. -- 真実はいつも一つ！/ 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
