Bug 1738290 - Review Request: libcamera - A library to support complex camera ISPs
Summary: Review Request: libcamera - A library to support complex camera ISPs
Keywords:
Status: CLOSED DUPLICATE of bug 2002417
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Javier Martinez Canillas
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: IoT
TreeView+ depends on / blocked
 
Reported: 2019-08-06 17:11 UTC by Peter Robinson
Modified: 2021-09-08 18:31 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-09-08 18:29:55 UTC
Type: Bug


Attachments (Terms of Use)
libcamera patch for unstable name (2.71 KB, patch)
2021-07-24 17:17 UTC, Dave Olsthoorn
no flags Details | Diff

Description Peter Robinson 2019-08-06 17:11:11 UTC
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

Comment 1 Peter Robinson 2019-08-06 17:46:38 UTC
koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=36835718

Comment 2 Xavier Bachelot 2019-08-07 16:35:11 UTC
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 ?

Comment 3 Robert-André Mauchin 🐧 2019-08-09 14:29:45 UTC
%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_name_versioning

Comment 4 Peter Robinson 2019-08-10 08:36:13 UTC
>  - 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.

Comment 5 Package Review 2020-08-10 00:45:24 UTC
This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.

You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.

Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.

Comment 6 Peter Robinson 2020-08-10 15:03:40 UTC
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.

Comment 7 Robert-André Mauchin 🐧 2020-08-26 14:47:49 UTC
NEEDINFO me when you're ready.

Comment 8 Dave Olsthoorn 2020-09-12 13:30:04 UTC
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

Comment 9 Robert-André Mauchin 🐧 2020-10-05 18:59:11 UTC
(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.

Comment 10 Peter Robinson 2020-10-05 19:22:56 UTC
I have this on my list for post F-33 GA to revisit.

Comment 11 jaskerx 2021-04-02 16:03:37 UTC
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.

Comment 12 Peter Robinson 2021-04-03 19:12:59 UTC
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.

Comment 15 Robert-André Mauchin 🐧 2021-04-05 16:30:28 UTC
 - 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_name_versioning

 - 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/#_snapshots

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.

Comment 16 Javier Martinez Canillas 2021-07-21 08:52:58 UTC
(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...

Comment 17 Peter Robinson 2021-07-21 08:58:14 UTC
> 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?

Comment 18 Javier Martinez Canillas 2021-07-21 09:05:12 UTC
(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/libcamera

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.

Comment 19 Nicolas Dufresne 2021-07-21 14:53:32 UTC
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.

Comment 20 Dave Olsthoorn 2021-07-24 17:17:27 UTC
Created attachment 1805238 [details]
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.

Comment 21 Javier Martinez Canillas 2021-09-07 07:58:30 UTC
(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.

Comment 22 Neal Gompa 2021-09-08 00:31:38 UTC
(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.

Comment 23 Javier Martinez Canillas 2021-09-08 15:05:08 UTC
(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.

Comment 24 Javier Martinez Canillas 2021-09-08 18:29:55 UTC

*** This bug has been marked as a duplicate of bug 2002417 ***

Comment 25 Javier Martinez Canillas 2021-09-08 18:31:26 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.