vasilito
f31522130f
Build system (5 gaps hardened): - COOKBOOK_OFFLINE defaults to true (fork-mode) - normalize_patch handles diff -ruN format - New 'repo validate-patches' command (25/25 relibc patches) - 14 patched Qt/Wayland/display recipes added to protected list - relibc archive regenerated with current patch chain Boot fixes (fixable): - Full ISO EFI partition: 16 MiB → 1 MiB (matches mini, BIOS hardcoded 2 MiB offset) - D-Bus system bus: absolute /usr/bin/dbus-daemon path (was skipped) - redbear-sessiond: absolute /usr/bin/redbear-sessiond path (was skipped) - daemon framework: silenced spurious INIT_NOTIFY warnings for oneshot_async services (P0-daemon-silence-init-notify.patch) - udev-shim: demoted INIT_NOTIFY warning to INFO (expected for oneshot_async) - relibc: comprehensive named semaphores (sem_open/close/unlink) replacing upstream todo!() stubs - greeterd: Wayland socket timeout 15s → 30s (compositor DRM wait) - greeter-ui: built and linked (header guard unification, sem_compat stubs removed) - mc: un-ignored in both configs, fixed glib/libiconv/pcre2 transitive deps - greeter config: removed stale keymapd dependency from display/greeter services - prefix toolchain: relibc headers synced, _RELIBC_STDLIB_H guard unified Unfixable (diagnosed, upstream): - i2c-hidd: abort on no-I2C-hardware (QEMU) — process::exit → relibc abort - kded6/greeter-ui: page fault 0x8 — Qt library null deref - Thread panics fd != -1 — Rust std library on Redox - DHCP timeout / eth0 MAC — QEMU user-mode networking - hwrngd/thermald — no hardware RNG/thermal in VM - live preload allocation — BIOS memory fragmentation, continues on demand
41 lines
1.8 KiB
Plaintext
41 lines
1.8 KiB
Plaintext
The release criteria for libdrm is essentially "if you need a release,
|
|
make one". There is no designated release engineer or maintainer.
|
|
Anybody is free to make a release if there's a certain feature or bug
|
|
fix they need in a released version of libdrm.
|
|
|
|
When new ioctl definitions are merged into drm-next, we will add
|
|
support to libdrm, at which point we typically create a new release.
|
|
However, this is up to whoever is driving the feature in question.
|
|
|
|
Follow these steps to release a new version of libdrm:
|
|
|
|
1) Bump the version number in meson.build. We seem to have settled for
|
|
2.4.x as the versioning scheme for libdrm, so just bump the micro
|
|
version.
|
|
|
|
2) Run `ninja -C builddir/ dist` to generate the tarballs.
|
|
Make sure that the version number of the tarball name in
|
|
builddir/meson-dist/ matches the number you bumped to. Move that
|
|
tarball to the libdrm repo root for the release script to pick up.
|
|
|
|
3) Push the updated main branch with the bumped version number:
|
|
|
|
git push origin main
|
|
|
|
assuming the remote for the upstream libdrm repo is called origin.
|
|
|
|
4) Use the release.sh script from the xorg/util/modular repo to
|
|
upload the tarballs to the freedesktop.org download area and
|
|
create an announce email template. The script takes one argument:
|
|
the path to the libdrm checkout. So, if a checkout of modular is
|
|
at the same level than the libdrm repo:
|
|
|
|
./modular/release.sh libdrm
|
|
|
|
This copies the two tarballs to freedesktop.org and creates
|
|
libdrm-2.4.16.announce which has a detailed summary of the
|
|
changes, links to the tarballs, MD5 and SHA1 sums and pre-filled
|
|
out email headers. Fill out the blank between the email headers
|
|
and the list of changes with a brief message of what changed or
|
|
what prompted this release. Send out the email and you're done!
|