https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Bug ID: 1738290 Summary: Review Request: libcamera - A library to support complex camera ISPs Product: Fedora Version: rawhide Status: NEW Component: Package Review Assignee: nobody@fedoraproject.org Reporter: pbrobinson@gmail.com QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org Target Milestone: --- Classification: Fedora
SPEC: https://pbrobinson.fedorapeople.org/libcamera.spec SRPM: https://pbrobinson.fedorapeople.org/libcamera-0.0.0-0.1.36d6229.fc30.src.rpm
Description: libcamera is a library that deals with heavy hardware image processing operations of complex camera devices that are shared between the linux host all while allowing offload of certain aspects to the control of complex camera hardware such as ISPs.
Hardware support includes USB UVC cameras, libv4l cameras as well as more complex ISPs (Image Signal Processor).
FAS: pbrobinson
koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=36835411
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Peter Robinson pbrobinson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1269538 (IoT)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1269538 [Bug 1269538] Tracker for IoT on Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #1 from Peter Robinson pbrobinson@gmail.com --- koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=36835718
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Xavier Bachelot xavier@bachelot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xavier@bachelot.org
--- Comment #2 from Xavier Bachelot xavier@bachelot.org --- Some notes from parsing the spec quickly : - The SCM and snapshot date should be mentioned in the Release: tag. https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
- Even if you're packaging a snapshot, you can have a full URL in Source0. https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
- I guess there's no versioned soname yet ?
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Robert-André Mauchin zebob.m@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zebob.m@gmail.com
--- Comment #3 from Robert-André Mauchin zebob.m@gmail.com --- %global commit 36d62298b20bec1f052fac04fd3011511cc29226 %global shortcommit %(c=%{commit}; echo ${c:0:7}) %global snapshotdate 20190809
Name: libcamera Version: 0 Release: 0.1%{?commit:.%{snapshotdate}git%{shortcommit}}%{?dist}
- Ask upstream to add soname versioning to their library. If they refuse, do it downstream: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_na...
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #4 from Peter Robinson pbrobinson@gmail.com ---
- Ask upstream to add soname versioning to their library. If they refuse,
do it downstream: https://docs.fedoraproject.org/en-US/packaging-guidelines/ #_downstream_so_name_versioning
I've spoken with upstream and they will be adding so name versioning closer to the first release, they don't feel it's ready for that yet and all the tools that currently use it are internal to the repo. Once they start adding support to things like gstreamer they will be versioning it.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Peter Robinson pbrobinson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(pbrobinson@gmail. | |com) |
--- Comment #6 from Peter Robinson pbrobinson@gmail.com --- Still working with upstream, will look at a rebase shortly. It's the way the new Raspberry Pi camera is supported so we still need it.
Product: Fedora Version: rawhide Component: Package Review
Peter Robinson pbrobinson@gmail.com has canceled Package Review package-review@lists.fedoraproject.org's request for Peter Robinson pbrobinson@gmail.com's needinfo: Bug 1738290: Review Request: libcamera - A library to support complex camera ISPs https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #6 from Peter Robinson pbrobinson@gmail.com --- Still working with upstream, will look at a rebase shortly. It's the way the new Raspberry Pi camera is supported so we still need it.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #7 from Robert-André Mauchin 🐧 zebob.m@gmail.com --- NEEDINFO me when you're ready.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Dave Olsthoorn dave.olsthoorn@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dave.olsthoorn@gmail.com
--- Comment #8 from Dave Olsthoorn dave.olsthoorn@gmail.com --- Since I was looking at libcamera for another project I rebased the spec file and made some other changes: - Add %check, it passed locally, but somehow not on koji - Splitting the existing package into muliple packages: separate docs, ipa modules and utilities - Disabling LTO, it broke the tests in %check - Adding some BuildRequires for new things: qcam, gstreamer plugin, ipa module signing and more Feel free to ignore if you don't want the changes I made:
SPEC: https://daveo.fedorapeople.org/review/libcamera/0.0.0-0.2.6f09a61/libcamera.... SRPM: https://daveo.fedorapeople.org/review/libcamera/0.0.0-0.2.6f09a61/libcamera-...
FAS: daveo
koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=51300458
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #9 from Robert-André Mauchin 🐧 zebob.m@gmail.com --- (In reply to Dave Olsthoorn from comment #8)
Since I was looking at libcamera for another project I rebased the spec file and made some other changes:
- Add %check, it passed locally, but somehow not on koji
- Splitting the existing package into muliple packages: separate docs, ipa
modules and utilities
- Disabling LTO, it broke the tests in %check
- Adding some BuildRequires for new things: qcam, gstreamer plugin, ipa
module signing and more Feel free to ignore if you don't want the changes I made:
SPEC: https://daveo.fedorapeople.org/review/libcamera/0.0.0-0.2.6f09a61/libcamera. spec SRPM: https://daveo.fedorapeople.org/review/libcamera/0.0.0-0.2.6f09a61/libcamera- 0.0.0-0.2.6f09a61.fc34.src.rpm
FAS: daveo
koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=51300458
Youneed to work with PRobinson on this, I can't approved a package for someone who is not the reporter.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #10 from Peter Robinson pbrobinson@gmail.com --- I have this on my list for post F-33 GA to revisit.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
jaskerx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jaskerx@gmail.com
--- Comment #11 from jaskerx@gmail.com --- FYI PipeWire recently started compiling against libcamera, so just a heads up, and I guess libcamera doesn't exactly have a versioned release yet either.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #12 from Peter Robinson pbrobinson@gmail.com --- I'll update this review shortly.
Still no versioned releases as yet, I'll reach out to upstream and see what their latest plans are, it's been a little while since I checked in with them.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #13 from Peter Robinson pbrobinson@gmail.com --- SPEC: https://pbrobinson.fedorapeople.org/libcamera.spec SRPM: https://pbrobinson.fedorapeople.org/libcamera-0.0.0-0.2.76a5861.fc34.src.rpm
koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=65221328
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #14 from Peter Robinson pbrobinson@gmail.com --- SPEC: https://pbrobinson.fedorapeople.org/libcamera.spec SRPM: https://pbrobinson.fedorapeople.org/libcamera-0.0.0-0.2.76a5861.fc34.src.rpm
koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=65224529
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #15 from Robert-André Mauchin 🐧 zebob.m@gmail.com --- - Not needed anymore:
%ldconfig_scriptlets
%ldconfig_scriptlets ipa
- %{_libdir}/libcamera*.so should be versioned, ask upstream to do so or do it locally for now. The unversioned should go into the devel subpackage then. See https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_na...
- The valid versioning for snapshots is as follow:
Either YYYYMMDD.<revision>
or YYYYMMDD<scm><revision>
See https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snaps...
Release: 0.2%{?snapshot:.%{snapshotdate}git%{snapshot}}%{?dist}
- Instead of providing the entire LICENSES folder, could you just include the ones that are actually used (LGPLv2.1+ and GPLv2)
- Use %global not %define:
%global _lto_cflags %{nil}
- Please split the description to stay below 80 characters per line:
libcamera.x86_64: E: description-line-too-long C libcamera is a library that deals with heavy hardware image processing operations libcamera.x86_64: E: description-line-too-long C of complex camera devices that are shared between the linux host all while allowing libcamera.x86_64: E: description-line-too-long C offload of certain aspects to the control of complex camera hardware such as ISPs. libcamera.x86_64: E: description-line-too-long C Hardware support includes USB UVC cameras, libv4l cameras as well as more complex
- Valid license shorthand is LGPLv2+:
libcamera.x86_64: W: invalid-license LGPLv2.1+
- You must delete the Sphinx build leftovers:
libcamera-docs.noarch: W: hidden-file-or-dir /usr/share/doc/libcamera-0.0.0/html/.buildinfo libcamera-docs.noarch: W: hidden-file-or-dir /usr/share/doc/libcamera-0.0.0/html/.doctrees libcamera-docs.noarch: W: hidden-file-or-dir /usr/share/doc/libcamera-0.0.0/html/.doctrees
- Escape the macros in comments with two %:
libcamera.src:13: W: macro-in-comment %{name} libcamera.src:13: W: macro-in-comment %{snapshot} libcamera.src:13: W: macro-in-comment %{snapshot} libcamera.src:13: W: macro-in-comment %{name} libcamera.src:13: W: macro-in-comment %{snapshot} libcamera.src: E: specfile-error warning: Macro expanded in comment on line 13: %{name}-%{snapshot}/ %{snapshot} | xz > %{name}-%{snapshot}.tar.xz
Package Review ==============
Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed
Issues: ======= - Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files directly in %_libdir. See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_devel_packages
===== MUST items =====
C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. [x]: Header files in -devel subpackage, if present. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs.
Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "*No copyright* Expat License GNU Lesser General Public License, Version 2.1 GNU General Public License, Version 2 Apache License 2.0", "*No copyright* Apache License 2.0", "BSD 2-clause "Simplified" License", "BSD 3-clause "New" or "Revised" License", "*No copyright* Creative Commons CC0 Universal 1.0 Public Domain Dedication", "GNU General Public License, Version 2", "GNU Lesser General Public License, Version 2.1", "[generated file]", "*No copyright* GNU Lesser General Public License, Version 2.1", "BSD 3-clause "New" or "Revised" License GNU General Public License v2.0 or later", "GNU General Public License, Version 2 [obsolete FSF postal address (Temple Place)]", "Apache License 2.0". 852 files have unknown license. Detailed output of licensecheck in /home/bob/packaging/review/libcamera/review-libcamera/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [x]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [!]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local
===== SHOULD items =====
Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [x]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in libcamera-docs [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [-]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [!]: Spec use %global instead of %define unless justified. Note: %define requiring justification: %define _lto_cflags %{nil} [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: The placement of pkgconfig(.pc) files are correct. [x]: SourceX is a working URL.
===== EXTRA items =====
Generic: [x]: Rpmlint is run on debuginfo package(s). Note: There are rpmlint messages (see attachment). [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Spec file according to URL is the same as in SRPM.
Rpmlint ------- Checking: libcamera-0.0.0-0.2.76a5861.fc35.x86_64.rpm libcamera-devel-0.0.0-0.2.76a5861.fc35.x86_64.rpm libcamera-docs-0.0.0-0.2.76a5861.fc35.noarch.rpm libcamera-ipa-0.0.0-0.2.76a5861.fc35.x86_64.rpm libcamera-tools-0.0.0-0.2.76a5861.fc35.x86_64.rpm libcamera-qcam-0.0.0-0.2.76a5861.fc35.x86_64.rpm libcamera-gstreamer-0.0.0-0.2.76a5861.fc35.x86_64.rpm libcamera-debuginfo-0.0.0-0.2.76a5861.fc35.x86_64.rpm libcamera-debugsource-0.0.0-0.2.76a5861.fc35.x86_64.rpm libcamera-0.0.0-0.2.76a5861.fc35.src.rpm libcamera.x86_64: E: description-line-too-long C libcamera is a library that deals with heavy hardware image processing operations libcamera.x86_64: E: description-line-too-long C of complex camera devices that are shared between the linux host all while allowing libcamera.x86_64: E: description-line-too-long C offload of certain aspects to the control of complex camera hardware such as ISPs. libcamera.x86_64: E: description-line-too-long C Hardware support includes USB UVC cameras, libv4l cameras as well as more complex libcamera.x86_64: W: invalid-license LGPLv2.1+ libcamera.x86_64: E: invalid-soname /usr/lib64/libcamera.so libcamera.so libcamera.x86_64: W: no-documentation libcamera-devel.x86_64: W: invalid-license LGPLv2.1+ libcamera-devel.x86_64: W: no-documentation libcamera-docs.noarch: W: invalid-license LGPLv2.1+ libcamera-docs.noarch: W: hidden-file-or-dir /usr/share/doc/libcamera-0.0.0/html/.buildinfo libcamera-docs.noarch: W: hidden-file-or-dir /usr/share/doc/libcamera-0.0.0/html/.doctrees libcamera-docs.noarch: W: hidden-file-or-dir /usr/share/doc/libcamera-0.0.0/html/.doctrees libcamera-docs.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/libcamera-0.0.0/html/objects.inv libcamera-docs.noarch: W: file-not-utf8 /usr/share/doc/libcamera-0.0.0/html/objects.inv libcamera-ipa.x86_64: W: invalid-license LGPLv2.1+ libcamera-ipa.x86_64: W: no-documentation libcamera-tools.x86_64: W: invalid-license LGPLv2.1+ libcamera-tools.x86_64: W: no-documentation libcamera-tools.x86_64: W: no-manual-page-for-binary cam libcamera-qcam.x86_64: W: invalid-license LGPLv2.1+ libcamera-qcam.x86_64: W: no-documentation libcamera-qcam.x86_64: W: no-manual-page-for-binary qcam libcamera-gstreamer.x86_64: W: description-shorter-than-summary libcamera-gstreamer.x86_64: W: invalid-license LGPLv2.1+ libcamera-gstreamer.x86_64: W: no-documentation libcamera-debuginfo.x86_64: W: invalid-license LGPLv2.1+ libcamera-debugsource.x86_64: W: invalid-license LGPLv2.1+ libcamera.src: E: description-line-too-long C libcamera is a library that deals with heavy hardware image processing operations libcamera.src: E: description-line-too-long C of complex camera devices that are shared between the linux host all while allowing libcamera.src: E: description-line-too-long C offload of certain aspects to the control of complex camera hardware such as ISPs. libcamera.src: E: description-line-too-long C Hardware support includes USB UVC cameras, libv4l cameras as well as more complex libcamera.src: W: invalid-license LGPLv2.1+ libcamera.src:13: W: macro-in-comment %{name} libcamera.src:13: W: macro-in-comment %{snapshot} libcamera.src:13: W: macro-in-comment %{snapshot} libcamera.src:13: W: macro-in-comment %{name} libcamera.src:13: W: macro-in-comment %{snapshot} libcamera.src: E: specfile-error warning: Macro expanded in comment on line 13: %{name}-%{snapshot}/ %{snapshot} | xz > %{name}-%{snapshot}.tar.xz 10 packages and 0 specfiles checked; 10 errors, 29 warnings.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Javier Martinez Canillas fmartine@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fmartine@redhat.com
--- Comment #16 from Javier Martinez Canillas fmartine@redhat.com --- (In reply to Peter Robinson from comment #12)
I'll update this review shortly.
Still no versioned releases as yet, I'll reach out to upstream and see what their latest plans are, it's been a little while since I checked in with them.
I've asked about this in the #libcamera channel today and the maintainer told me the following:
<pinchartl> | javierm: very very tentatively, I'd say in ~6 months
I wonder how we should proceed, if having a downstream patch to add a .so name versioning as suggested in Comment #3 (and deal with any fallout caused by the API/ABI to change before they cut a versioned release) or just wait until they do that...
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #17 from Peter Robinson pbrobinson@gmail.com ---
I wonder how we should proceed, if having a downstream patch to add a .so name versioning as suggested in Comment #3 (and deal with any fallout caused by the API/ABI to change before they cut a versioned release) or just wait until they do that...
The problem we have with patching it downstream if we end up with a conflicting versioning, or if we have to patch any app/library that may currently support libcamera to support the versioned libraries.
I suppose the real question is what users outside of the libcamera included utilities do we currently have to utilise libcamera? AKA what currently has support for it?
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #18 from Javier Martinez Canillas fmartine@redhat.com --- (In reply to Peter Robinson from comment #17)
I wonder how we should proceed, if having a downstream patch to add a .so name versioning as suggested in Comment #3 (and deal with any fallout caused by the API/ABI to change before they cut a versioned release) or just wait until they do that...
The problem we have with patching it downstream if we end up with a conflicting versioning, or if we have to patch any app/library that may currently support libcamera to support the versioned libraries.
I suppose the real question is what users outside of the libcamera included utilities do we currently have to utilise libcamera? AKA what currently has support for it?
The only user I know about (because the GStreamer element is currently part of libcamera as well) is PipeWire (when built with -Dlibcamera=true):
https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/spa/plugins/l...
Since having libcamera is the only way to support the camera in some devices (i.e: rpi4), I think that I'm leaning towards carry a downstream patch in the meantime.
I'm happy to take over this pkg and also coordinate with Wim for the PipeWire bits.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Nicolas Dufresne nicolas@ndufresne.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nicolas@ndufresne.ca
--- Comment #19 from Nicolas Dufresne nicolas@ndufresne.ca --- Hi Folks, as libcamera is not yet to a point were it can be released with a version, I would recommend going further then just the Fedora packaging rules. I would suggest to patch libcamera to rename the library, I would propose libcamera-unstable.so.X.Y. This way, you can pretty much be guarantee to never clash with a stable version of the SO.
As for the users of libcamera, the GStreamer element rely on stable GStreamer release, but unstable libcamera, and that's why we placed inside libcamera. For the SPA plugin, inside of PipeWire, it depends on both unstable libcamera and SPA interface. Someone had to decide. Note that the libcamera SPA plugin is mostly a proof-of-concept. It is meant to cover the legacy use cases, single stream, that is covered by the V4L2 SPA plugin. It is also not very "real time" friendly, as libcamera API does a lot of run-time allocation. A proper libcamera / PipeWire integration will be needed to allow configuring multiple streams on the RPi or other modern SoC (including Intel IPU3) based cameras.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #20 from Dave Olsthoorn dave@bewaar.me --- Created attachment 1805238 --> https://bugzilla.redhat.com/attachment.cgi?id=1805238&action=edit libcamera patch for unstable name
Here is a patch adding the unstable postfix to the library name, it also overrides the pkgconfig filenames back to the original names to allow it to be used.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Javier Martinez Canillas fmartine@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|nobody@fedoraproject.org |fmartine@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #21 from Javier Martinez Canillas fmartine@redhat.com --- (In reply to Nicolas Dufresne from comment #19)
Hi Folks, as libcamera is not yet to a point were it can be released with a version, I would recommend going further then just the Fedora packaging rules. I would suggest to patch libcamera to rename the library, I would propose libcamera-unstable.so.X.Y. This way, you can pretty much be
I would prefer to minimize the downstream patching if possible.
guarantee to never clash with a stable version of the SO.
Discussed this with the upstream libcamera maintainers (Laurent Pinchart and Kieran Bingham), they said that downstream distros can rely on the following:
1) The first commit would be considered version 0.0.0 (they will tag it).
2) If they ever bump the 'version' field in the meson.build file, they will tag that commit as well. So even when they won't release tarballs until there is a stable API, distros can follow that versioning in packages.
3) The first stable release will be 1.0 and they will both tag the commit and release a tarball when this happens.
I believe is safe given these assumptions to use the 'Version: 0.0.0' and 'Release: 0.1%{?snapshot:.%{snapshot}}%{?dist}' as pbrobinson did in his SPEC.
Fedora can then bump the 'Version' if upstream bumps theirs, and just the 0.x in the 'Release' if the package is rebased to a newer git snapshot.
Maybe even using just 'Release: 1%{?snapshot:.%{snapshot}}%{?dist}' since the 'Version' already contains 0.0.0, making it clear that's a non stable version.
I will take on this bugzilla and try to move the libcamera packaging forward.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Neal Gompa ngompa13@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ngompa13@gmail.com
--- Comment #22 from Neal Gompa ngompa13@gmail.com --- (In reply to Javier Martinez Canillas from comment #21)
I will take on this bugzilla and try to move the libcamera packaging forward.
Please close this BZ for a new review request, so that the eventual approval will actually work properly.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #23 from Javier Martinez Canillas fmartine@redhat.com --- (In reply to Neal Gompa from comment #22)
(In reply to Javier Martinez Canillas from comment #21)
I will take on this bugzilla and try to move the libcamera packaging forward.
Please close this BZ for a new review request, so that the eventual approval will actually work properly.
Ok, will do.
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
Javier Martinez Canillas fmartine@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |DUPLICATE Last Closed| |2021-09-08 18:29:55
--- Comment #24 from Javier Martinez Canillas fmartine@redhat.com ---
*** This bug has been marked as a duplicate of bug 2002417 ***
https://bugzilla.redhat.com/show_bug.cgi?id=1738290
--- Comment #25 from Javier Martinez Canillas fmartine@redhat.com --- (In reply to Robert-André Mauchin 🐧 from comment #15)
- Not needed anymore:
%ldconfig_scriptlets
%ldconfig_scriptlets ipa
- %{_libdir}/libcamera*.so should be versioned, ask upstream to do so or do
it locally for now. The unversioned should go into the devel subpackage then. See
[snip]
I think that addressed all the issues you pointed out and filed a new bug 2002417 as requested by Neal.
package-review@lists.fedoraproject.org
-
bugzilla＠redhat.com