https://bugzilla.redhat.com/show_bug.cgi?id=2332914
Bug ID: 2332914
Summary: Review Request: quickemu - Wrapper around QEMU/KVM for
rapid desktop VM spin-up and management
Product: Fedora
Version: rawhide
Hardware: All
OS: Linux
Status: NEW
Component: Package Review
Severity: medium
Assignee: nobody(a)fedoraproject.org
Reporter: alex(a)alexhaydock.co.uk
QA Contact: extras-qa(a)fedoraproject.org
CC: package-review(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Spec URL:
https://github.com/alexhaydock/quickemu-fedora/blob/main/quickemu-fedora.sp…
SRPM URL:
https://copr.fedorainfracloud.org/coprs/alexhaydock/quickemu/build/8404445/
Description: Quickemu is a bash-based wrapper around QEMU/KVM for rapidly
spinning up desktop VMs for testing or general usage
Fedora Account System Username: alexhaydock
Hi!
This is my first package for Fedora and I'm looking for a sponsor.
I'm a security engineer / security-focused sysadmin with 10+ years of
experience deploying and maintaining Linux-based infrastructure, and experience
of Fedora since Fedora 14.
I'm looking to start packaging software for Fedora and this is a simple first
package to begin with. It is written in bash and essentially wraps around the
native QEMU featureset to make configuring and deploying local desktop VMs with
graphical acceleration extremely convenient. It has a dedicated community and
sees reasonably active development.
I'm happy to maintain this package in Fedora myself, or pass it on to someone
else. In fact, learning the packaging and maintainership flow of Fedora is the
primary motivation for attempting to package this software - aside from the
fact that I do use it frequently myself.
My hope is to be able to package this simple app before moving onto more
complicated applications. I have some security tooling in mind which I'd like
to take through the whole Fedora > EPEL > CentOS > RHEL flow if possible.
Starting simple with this package made more sense though, as the first security
tool I'm looking to package involves more complex concepts such as user
management and shipping SELinux policies.
I am not the upstream maintainer of this package, but if the package is
accepted into Fedora I will submit all the relevant information to them and PRs
to update the documentation etc to make it clear that it is now natively
packaged.
Would appreciate any help from any packagers out there so I can start trying to
contribute to Fedora :)
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2332914
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2368737
Bug ID: 2368737
Summary: Review Request: cef - Chromium Embedded Framework
Product: Fedora
Version: rawhide
Hardware: All
OS: Linux
Status: NEW
Component: Package Review
Severity: medium
Priority: medium
Assignee: nobody(a)fedoraproject.org
Reporter: lina(a)asahilina.net
QA Contact: extras-qa(a)fedoraproject.org
CC: package-review(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Spec URL: https://asahilina.fedorapeople.org/cef.spec
SRPM URL:
https://asahilina.net/files/cef-136.1.6^chromium136.0.7103.113-1.fc42.src.r…
Description: CEF is an embeddable build of Chromium, powered by WebKit (Blink).
Fedora Account System Username: asahilina
For ease of review: https://asahilina.fedorapeople.org/mkspec.sh (SPECPARTS
generator, also because the SRPM one is slightly outdated as I just added the
cef-api RPM macros)
This package supersedes `obs-cef` (exists in F40, dropped in F41 due to FTBFS),
which was an OBS-specific CEF fork. OBS now uses upstream CEF, and upstream CEF
is starting to have API/ABI compatibility guarantees, which means it's now
sensible to package CEF as a shared package. The latest stable CEF version
closely follows stable Chromium releases, so it becomes viable to have this
package track the release of the chromium package in Fedora, which makes things
much nicer.
I'm still running test builds, but I think the spec file as above should build
fine (a piece-wise RPM build on aarch64 worked). I will probably have to fix
minor things (build config tweaks and possibly some bugfix patches after
testing with OBS) before this is ready for release, but it should be ready for
package review.
The general approach is to take chromium.spec and make a series of contained
changes, keeping as much as possible untouched, so that chromium.spec bumps can
be tracked more easily. The Chromium release used for CEF is not necessarily
the same as upstream CEF (here, we use 136.0.7103.113 while upstream CEF uses
136.0.7103.114), as prefer to track the chromium.spec version so that the same
chromium source tarball can be used. In general, the CEF build should be
relatively insensitive to chromium patch version differences.
ABI versioning works like this:
- There is an EXPERIMENTAL API version which is only compatible with a precise
CEF version (major/minor/patch, not including the Chromium components)
- There is a set of ABI versions which any given CEF version is compatible
with.
- Solib versioning is not used since it cannot encode the above semantics.
We encode those as:
Provides: cef(abi) = 136.1.6
Provides: cef(api) = 13300
Provides: cef(api) = 13301
[...]
Provides: cef(api) = 13601 (note: this matches the 136.1 version number
portion)
Each API version comes with a libcef_dll_wrapper.a static library to be linked
into consumers. These are provided prebuilt alongside headers in multiple
mutually exclusive cef-[api-NNNN-]devel subpackages, one per API version. The
consumer is expected to BuildRequires the appropriate one, and also set
-DCEF_API_VERSION=NNNN during its build (to request a non-EXPERIMENTAL
release). The header files for each subpackage have a check injected to fail
the build if the define is not set correctly. The consumer should also use
%{?_cef_api_requires} in its spec, which will pull in the correct runtime
dependency. At runtime, any consumer built with an explicit API version should
be upwards compatible with newer libcef.so versions as long as they do not drop
that API from the support list, while the unversioned EXPERIMENTAL API forces a
specific CEF version (excluding the Chromium subcomponent, so Chromium patch
level updates are still possible e.g. to fix security bugs).
Depending on how maintenance goes and whether OBS ends up working with the
versioned API, I might later introduce an override for the cef(abi) provide, to
allow CEF patch version updates that are known (by inspection) not to break the
EXPERIMENTAL ABI (even though upstream doesn't promise that) without rebuilding
consumers.
Note: This has ppc64le builds enabled, though I have no idea if they'll work.
If they don't I'll disable it and leave it as aarch64/x86_64.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
https://bugzilla.redhat.com/show_bug.cgi?id=2368737
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…