Re: Storing package metadata in ELF objects
by Luca Boccassi
On Sat, 2021-04-10 at 13:29 +0100, Luca Boccassi wrote:
> Hello,
>
> Cross-posting to the mailing lists of a few relevant projects.
>
> After an initial discussion [0], recently we have been working on a new
> specification [0] to encode rich package-level metadata inside ELF
> objects, so that it can be included automatically in generated coredump
> files. The prototype to parse this in systemd-coredump and store the
> information in systemd-journal is ready for testing and merged
> upstream. We are now seeking further comments/opinions/suggestions, as
> we have a few months before the next release and thus there's plenty of
> time to make incompatible changes to the format and implementation, if
> required.
>
> A proposal to use this by default for all packages built in Fedora 35
> has been submitted [1].
>
> The Fedora Wiki and the systemd.io document have more details, but to
> make a long story short, a new .notes.package section with a JSON
> payload will be included in ELF objects, encoding various package-
> build-time information like distro name&version, package name&version,
> etc.
>
> To summarize from the discussion, the main reasons why we believe this
> is useful are as following:
>
> 1) minimal containers: the rpm database is not installed in the
> containers. The information about build-ids needs to be stored
> externally, so package name information is not available immediately,
> but only after offline processing. The new note doesn't depend on the
> rpm db in any way.
>
> 2) handling of a core from a container, where the container and host
> have different distros
>
> 3) self-built and external packages: unless a lot of care is taken to
> keep access to the debuginfo packages, this information may be lost.
> The new note is available even if the repository metadata gets lost.
> Users can easily provide equivalent information in a format that makes
> sense in their own environment. It should work even when rpms and debs
> and other formats are mixed, e.g. during container image creation.
>
> Other than in Fedora, we are already making the required code changes
> at Microsoft to use the same format&specification for internally-built
> binaries, and for tools that parse core files and logs.
>
> Tools for RPM and DEB (debhelper) integration are also available [3].
Wrong Fedora list address - off to a great start already :-)
(fixed now)
--
Kind regards,
Luca Boccassi
2 years, 12 months
Wayland and basic graphics mode
by Neal Gompa
Hey all,
During the final days of Fedora Linux 34 development, it was
discovered that Plasma Wayland hangs when kernel modesetting isn't
available[1]. It was resolved for F34 with a downstream change to sddm
that checks if "nomodeset" is set and disables Wayland sessions
accordingly.
However, this is not a sustainable solution. Technically, Plasma
Wayland supports fbdev, but it is not very good relative to the
standard drm backend (and requires extra configuration to work).
Additionally, GNOME Wayland *only* supports the drm backend and it
fails entirely when "nomodeset" is set, thus GDM forces back to X11 in
this scenario. As we move forward with adopting Wayland across the
board, variations of this problem will happen over and over again.
So my questions are:
Do we want to support a "basic graphics mode"? If so (which I think we
do), are there any alternatives to disabling KMS entirely that we
could use? Perhaps vkms[2] is an option? If not, what do we do about
it?
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1952431
[2]: https://dri.freedesktop.org/docs/drm/gpu/vkms.html
--
真実はいつも一つ！/ Always, there's only one truth!
2 years, 12 months
PETSc 3.15
by Antonio T. sagitter
Hi all.
PETSc 3.15 is coming in Rawhide branch.
Release notes: https://www.mcs.anl.gov/petsc/documentation/changes/315.html
Dependencies in Fedora:
$ repoquery --disablerepo=* --enablerepo=fedora*-source --whatrequires
petsc-openmpi-devel
bout++-0:4.3.1-7.fc33.src
freefem++-0:4.6-6.fc33.src
petsc4py-0:3.13.0-5.fc33.src
python-steps-0:3.5.0-5.fc33.src
--
---
Antonio Trande
Fedora Project
mailto: sagitter(a)fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/
2 years, 12 months
