[libcamera-devel,RFC] package/libcamera: Add libcamera package

741 diff mbox series

http://libcamera.org/

Cameras are complex devices that need heavy hardware image processing
operations. Control of the processing is based on advanced algorithms
that must run on a programmable processor. This has traditionally been
implemented in a dedicated MCU in the camera, but in embedded devices
algorithms have been moved to the main CPU to save cost. Blurring the
boundary between camera devices and Linux often left the user with no
other option than a vendor-specific closed-source solution.

To address this problem the Linux media community has very recently
started collaboration with the industry to develop a camera stack that
will be open-source-friendly while still protecting vendor core IP.
libcamera was born out of that collaboration and will offer modern
camera support to Linux-based systems, including traditional Linux
distributions, ChromeOS and Android.

Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
We do not yet have an official 'release', so I'm sending this as an
early RFC, with
  LIBCAMERA_VERSION = origin/master
and no .hash file.

Is this still suitable to go in and be updated when we have a tagged
release later?


 DEVELOPERS                     |  3 +++
 package/Config.in              |  1 +
 package/libcamera/Config.in    | 11 +++++++++++
 package/libcamera/libcamera.mk | 13 +++++++++++++
 4 files changed, 28 insertions(+)
 create mode 100644 package/libcamera/Config.in
 create mode 100644 package/libcamera/libcamera.mk

Hi All,

On 19/03/2019 11:03, Kieran Bingham wrote:
>   http://libcamera.org/
> 
> Cameras are complex devices that need heavy hardware image processing
> operations. Control of the processing is based on advanced algorithms
> that must run on a programmable processor. This has traditionally been
> implemented in a dedicated MCU in the camera, but in embedded devices
> algorithms have been moved to the main CPU to save cost. Blurring the
> boundary between camera devices and Linux often left the user with no
> other option than a vendor-specific closed-source solution.
> 
> To address this problem the Linux media community has very recently
> started collaboration with the industry to develop a camera stack that
> will be open-source-friendly while still protecting vendor core IP.
> libcamera was born out of that collaboration and will offer modern
> camera support to Linux-based systems, including traditional Linux
> distributions, ChromeOS and Android.
> 
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> We do not yet have an official 'release', so I'm sending this as an
> early RFC, with
>   LIBCAMERA_VERSION = origin/master
> and no .hash file.
> 
> Is this still suitable to go in and be updated when we have a tagged
> release later?



As discussed on IRC, no - this is not acceptable. So I'll update this
with a specific commit hash (after I fix the compiler warning that
buildroot flushed out for us :D )


Any comments on the rest are welcome still of course!

--
Kieran


> 
> 
>  DEVELOPERS                     |  3 +++
>  package/Config.in              |  1 +
>  package/libcamera/Config.in    | 11 +++++++++++
>  package/libcamera/libcamera.mk | 13 +++++++++++++
>  4 files changed, 28 insertions(+)
>  create mode 100644 package/libcamera/Config.in
>  create mode 100644 package/libcamera/libcamera.mk
> 
> diff --git a/DEVELOPERS b/DEVELOPERS
> index c91325e28486..5bcdf208a62b 100644
> --- a/DEVELOPERS
> +++ b/DEVELOPERS
> @@ -1260,6 +1260,9 @@ F:	package/ramsmp/
>  N:	Kevin Joly <kevin.joly@sensefly.com>
>  F:	package/libgphoto2/
>  
> +N:	Kieran Bingham <kieran.bingham@ideasonboard.com>
> +F:	package/libcamera/
> +
>  N:	Koen Martens <gmc@sonologic.nl>
>  F:	package/capnproto/
>  F:	package/linuxconsoletools/
> diff --git a/package/Config.in b/package/Config.in
> index b5321aeb49c9..a9d25e58b202 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -1472,6 +1472,7 @@ menu "Multimedia"
>  	source "package/libass/Config.in"
>  	source "package/libbdplus/Config.in"
>  	source "package/libbluray/Config.in"
> +	source "package/libcamera/Config.in"
>  	source "package/libdcadec/Config.in"
>  	source "package/libdvbcsa/Config.in"
>  	source "package/libdvbpsi/Config.in"
> diff --git a/package/libcamera/Config.in b/package/libcamera/Config.in
> new file mode 100644
> index 000000000000..c80f58c00f17
> --- /dev/null
> +++ b/package/libcamera/Config.in
> @@ -0,0 +1,11 @@
> +config BR2_PACKAGE_LIBCAMERA
> +	bool "libcamera"
> +	depends on BR2_INSTALL_LIBSTDCPP
> +	depends on BR2_TOOLCHAIN_HAS_THREADS
> +	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 # C++11
> +	depends on BR2_PACKAGE_HAS_UDEV
> +	help
> +	  libcamera provides a software stack to support complex devices that
> +	  need heavy hardware image processing operations.
> +
> +	  http://www.libcamera.org/
> diff --git a/package/libcamera/libcamera.mk b/package/libcamera/libcamera.mk
> new file mode 100644
> index 000000000000..4d908c7a3645
> --- /dev/null
> +++ b/package/libcamera/libcamera.mk
> @@ -0,0 +1,13 @@
> +################################################################################
> +#
> +# libcamera
> +#
> +################################################################################
> +
> +LIBCAMERA_VERSION = origin/master
> +LIBCAMERA_SITE = git://linuxtv.org/libcamera.git
> +LIBCAMERA_SITE_METHOD = git
> +LIBCAMERA_DEPENDENCIES = udev
> +LIBCAMERA_LICENSE = LGPL-2.0+
> +
> +$(eval $(meson-package))
>

Kieran, All,

On 2019-03-19 11:03 +0000, Kieran Bingham spake thusly:
>   http://libcamera.org/
> 
> Cameras are complex devices that need heavy hardware image processing
> operations. Control of the processing is based on advanced algorithms
> that must run on a programmable processor. This has traditionally been
> implemented in a dedicated MCU in the camera, but in embedded devices
> algorithms have been moved to the main CPU to save cost. Blurring the
                                                           ^^^^^^^^
I see what you did there! ;-)

> boundary between camera devices and Linux often left the user with no
> other option than a vendor-specific closed-source solution.
> 
> To address this problem the Linux media community has very recently
> started collaboration with the industry to develop a camera stack that
> will be open-source-friendly while still protecting vendor core IP.
> libcamera was born out of that collaboration and will offer modern
> camera support to Linux-based systems, including traditional Linux
> distributions, ChromeOS and Android.

While I appreciate the blurb about the context around libcamera, what I
find even more interesting in a commit log is an explanations about the
complexity of the packaging in Buildrot, and why such or such hack was
done.

Here, you don't seem to have much to say, though, except...

> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> We do not yet have an official 'release', so I'm sending this as an
> early RFC, with
>   LIBCAMERA_VERSION = origin/master
> and no .hash file.

... this blurb would have had its place in the commit log:

    The project has not made an official release as of yet, so we're
    using the latest sha1 from master.

which is about the only thing that I find important for a commit in
Buildroot.

> Is this still suitable to go in and be updated when we have a tagged
> release later?

As I explained on IRC, using a branch name is not acceptable, because it
does not work as you think it would, as explaiend in the manual (quting
here for your convenience):

    Note: Using a branch name as FOO_VERSION is not supported, because it
    does not and can not work as people would expect it should:

     1. due to local caching, Buildroot will not re-fetch the repository, so
        people who expect to be able to follow the remote repository would be
        quite surprised and disappointed;
     2. because two builds can never be perfectly simultaneous, and because
        the remote repository may get new commits on the branch anytime, two
        users, using the same Buildroot tree and building the same
        configuration, may get different source, thus rendering the build non
        reproducible, and people would be quite surprised and disappointed. 

So, use a sha1. ;-)

>  DEVELOPERS                     |  3 +++
>  package/Config.in              |  1 +
>  package/libcamera/Config.in    | 11 +++++++++++
>  package/libcamera/libcamera.mk | 13 +++++++++++++
>  4 files changed, 28 insertions(+)
>  create mode 100644 package/libcamera/Config.in
>  create mode 100644 package/libcamera/libcamera.mk
> 
> diff --git a/DEVELOPERS b/DEVELOPERS
> index c91325e28486..5bcdf208a62b 100644
> --- a/DEVELOPERS
> +++ b/DEVELOPERS
> @@ -1260,6 +1260,9 @@ F:	package/ramsmp/
>  N:	Kevin Joly <kevin.joly@sensefly.com>
>  F:	package/libgphoto2/
>  
> +N:	Kieran Bingham <kieran.bingham@ideasonboard.com>
> +F:	package/libcamera/

Nice, thanks! :-)

> diff --git a/package/libcamera/Config.in b/package/libcamera/Config.in
> new file mode 100644
> index 000000000000..c80f58c00f17
> --- /dev/null
> +++ b/package/libcamera/Config.in
> @@ -0,0 +1,11 @@
> +config BR2_PACKAGE_LIBCAMERA
> +	bool "libcamera"
> +	depends on BR2_INSTALL_LIBSTDCPP
> +	depends on BR2_TOOLCHAIN_HAS_THREADS
> +	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 # C++11
> +	depends on BR2_PACKAGE_HAS_UDEV
> +	help
> +	  libcamera provides a software stack to support complex devices that
> +	  need heavy hardware image processing operations.

Did you pass this package through utils/check-package?

    package/libcamera/Config.in:8: help text: <tab><2 spaces><62 chars>
    (http://nightly.buildroot.org/#writing-rules-config-in)
    24 lines processed
    1 warnings generated

Also, as you already discovered, it's nice to pass a new package through
utils/test-pkg as well (and although not mandatory, it's nice to provide
that report after the --- line.)

> +	  http://www.libcamera.org/
> diff --git a/package/libcamera/libcamera.mk b/package/libcamera/libcamera.mk
> new file mode 100644
> index 000000000000..4d908c7a3645
> --- /dev/null
> +++ b/package/libcamera/libcamera.mk
> @@ -0,0 +1,13 @@
> +################################################################################
> +#
> +# libcamera
> +#
> +################################################################################
> +
> +LIBCAMERA_VERSION = origin/master
> +LIBCAMERA_SITE = git://linuxtv.org/libcamera.git

Please use the https (or http) URI, as people usually can't use the git
protocol from behind nasty corporate-class firewalls.

> +LIBCAMERA_SITE_METHOD = git
> +LIBCAMERA_DEPENDENCIES = udev
> +LIBCAMERA_LICENSE = LGPL-2.0+

This is not LGPL-2.0+, but LGPL-2.1+

There are actually 2 other licenses applicable to this package: GPLv2.0+
and CC-BY-SA-4.0 (or later?).

We usually specify what part of the package they apply to (correct me
if/where I am wrong):

    LIBCAMERA_LICENSE = LGPL-2.1+ (library), GPL-2.0+ (utils, test), CC-By_SA-4.0 (doc)

Please also specify the files that contain the license texts:

    LIBCAMERA_LICENSE_FILES = \
        licenses/cc-by-sa-v4.0.txt \
        licenses/developer-certificate-of-origin.txt \
        licenses/gnu-gpl-2.0.txt \
        licenses/gnu-lgpl-2.1.txt

Thanks! :-)

Regards,
Yann E. MORIN.

> +
> +$(eval $(meson-package))
> -- 
> 2.19.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Hi Yann,

Thank you for the review,

On 19/03/2019 12:50, Yann E. MORIN wrote:
> Kieran, All,
> 
> On 2019-03-19 11:03 +0000, Kieran Bingham spake thusly:
>>   http://libcamera.org/
>>
>> Cameras are complex devices that need heavy hardware image processing
>> operations. Control of the processing is based on advanced algorithms
>> that must run on a programmable processor. This has traditionally been
>> implemented in a dedicated MCU in the camera, but in embedded devices
>> algorithms have been moved to the main CPU to save cost. Blurring the
>                                                            ^^^^^^^^
> I see what you did there! ;-)

Cameras on these new platforms are certainly blurry without some new
software support :)

But yes, this was the blurb from libcamera.org to provide context of the
library addition.

>> boundary between camera devices and Linux often left the user with no
>> other option than a vendor-specific closed-source solution.
>>
>> To address this problem the Linux media community has very recently
>> started collaboration with the industry to develop a camera stack that
>> will be open-source-friendly while still protecting vendor core IP.
>> libcamera was born out of that collaboration and will offer modern
>> camera support to Linux-based systems, including traditional Linux
>> distributions, ChromeOS and Android.
> 
> While I appreciate the blurb about the context around libcamera, what I
> find even more interesting in a commit log is an explanations about the
> complexity of the packaging in Buildrot, and why such or such hack was

Buildrot? I hope that's not some sort of freudian slip :-)


> done.
> 
> Here, you don't seem to have much to say, though, except...
> 
>> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
>> ---
>> We do not yet have an official 'release', so I'm sending this as an
>> early RFC, with
>>   LIBCAMERA_VERSION = origin/master
>> and no .hash file.
> 
> ... this blurb would have had its place in the commit log:

I think I essentially knew origin/master was not going to be acceptable,
hence it was RFC to find out the right thing to do and I had only put
this in the comments,

> 
>     The project has not made an official release as of yet, so we're
>     using the latest sha1 from master.

I agree, This is a good addition to the commit message.


> 
> which is about the only thing that I find important for a commit in
> Buildroot.
> 
>> Is this still suitable to go in and be updated when we have a tagged
>> release later?
> 
> As I explained on IRC, using a branch name is not acceptable, because it
> does not work as you think it would, as explaiend in the manual (quting
> here for your convenience):
> 
>     Note: Using a branch name as FOO_VERSION is not supported, because it
>     does not and can not work as people would expect it should:
> 
>      1. due to local caching, Buildroot will not re-fetch the repository, so
>         people who expect to be able to follow the remote repository would be
>         quite surprised and disappointed;
>      2. because two builds can never be perfectly simultaneous, and because
>         the remote repository may get new commits on the branch anytime, two
>         users, using the same Buildroot tree and building the same
>         configuration, may get different source, thus rendering the build non
>         reproducible, and people would be quite surprised and disappointed. 
> 
> So, use a sha1. ;-)

Agreed. I'll hold off until the fix required to get compilation to work
in buildroot is in... which shouldn't be long :)



> 
>>  DEVELOPERS                     |  3 +++
>>  package/Config.in              |  1 +
>>  package/libcamera/Config.in    | 11 +++++++++++
>>  package/libcamera/libcamera.mk | 13 +++++++++++++
>>  4 files changed, 28 insertions(+)
>>  create mode 100644 package/libcamera/Config.in
>>  create mode 100644 package/libcamera/libcamera.mk
>>
>> diff --git a/DEVELOPERS b/DEVELOPERS
>> index c91325e28486..5bcdf208a62b 100644
>> --- a/DEVELOPERS
>> +++ b/DEVELOPERS
>> @@ -1260,6 +1260,9 @@ F:	package/ramsmp/
>>  N:	Kevin Joly <kevin.joly@sensefly.com>
>>  F:	package/libgphoto2/
>>  
>> +N:	Kieran Bingham <kieran.bingham@ideasonboard.com>
>> +F:	package/libcamera/
> 
> Nice, thanks! :-)


Is it possible to put the libcamera mailinglist as a 'cc' target here as
well? or is it only individuals.

If someone (other than me) updates the package, It would be nice for
that notification to go to the list.


>> diff --git a/package/libcamera/Config.in b/package/libcamera/Config.in
>> new file mode 100644
>> index 000000000000..c80f58c00f17
>> --- /dev/null
>> +++ b/package/libcamera/Config.in
>> @@ -0,0 +1,11 @@
>> +config BR2_PACKAGE_LIBCAMERA
>> +	bool "libcamera"
>> +	depends on BR2_INSTALL_LIBSTDCPP
>> +	depends on BR2_TOOLCHAIN_HAS_THREADS
>> +	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 # C++11
>> +	depends on BR2_PACKAGE_HAS_UDEV
>> +	help
>> +	  libcamera provides a software stack to support complex devices that
>> +	  need heavy hardware image processing operations.
> 
> Did you pass this package through utils/check-package?
> 
>     package/libcamera/Config.in:8: help text: <tab><2 spaces><62 chars>
>     (http://nightly.buildroot.org/#writing-rules-config-in)
>     24 lines processed
>     1 warnings generated

I thought I had - but had no output, so clearly I failed :(
I was incorrectly wrapping at 72. I've now re-wrapped at 62.


> Also, as you already discovered, it's nice to pass a new package through
> utils/test-pkg as well (and although not mandatory, it's nice to provide
> that report after the --- line.)

I was going to ask how to do this - as it was skipping all 6, and then
all 43 toolchains with -a. But I've worked it out, so for the benefit of
others:

I had to create a libcamera.config and specify the EUDEV dependency:

  BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
  BR2_PACKAGE_LIBCAMERA=y

Then:
 ./utils/test-pkg -c libcamera.config -p libcamera


It's now running, and I assume it will take some time...


>> +	  http://www.libcamera.org/
>> diff --git a/package/libcamera/libcamera.mk b/package/libcamera/libcamera.mk
>> new file mode 100644
>> index 000000000000..4d908c7a3645
>> --- /dev/null
>> +++ b/package/libcamera/libcamera.mk
>> @@ -0,0 +1,13 @@
>> +################################################################################
>> +#
>> +# libcamera
>> +#
>> +################################################################################
>> +
>> +LIBCAMERA_VERSION = origin/master
>> +LIBCAMERA_SITE = git://linuxtv.org/libcamera.git
> 
> Please use the https (or http) URI, as people usually can't use the git
> protocol from behind nasty corporate-class firewalls.
> 
>> +LIBCAMERA_SITE_METHOD = git
>> +LIBCAMERA_DEPENDENCIES = udev
>> +LIBCAMERA_LICENSE = LGPL-2.0+
> 
> This is not LGPL-2.0+, but LGPL-2.1+

Ugh, I should have remembered that, especially as I added the licenses...

> 
> There are actually 2 other licenses applicable to this package: GPLv2.0+
> and CC-BY-SA-4.0 (or later?).
> 
> We usually specify what part of the package they apply to (correct me
> if/where I am wrong):
> 
>     LIBCAMERA_LICENSE = LGPL-2.1+ (library), GPL-2.0+ (utils, test), CC-By_SA-4.0 (doc)


That looks accurate to me.

I've updated the patch.

> 
> Please also specify the files that contain the license texts:
> 
>     LIBCAMERA_LICENSE_FILES = \
>         licenses/cc-by-sa-v4.0.txt \
>         licenses/developer-certificate-of-origin.txt \
>         licenses/gnu-gpl-2.0.txt \
>         licenses/gnu-lgpl-2.1.txt
> 

along with this.


> Thanks! :-)
> 
> Regards,
> Yann E. MORIN.
> 
>> +
>> +$(eval $(meson-package))
>> -- 
>> 2.19.1
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot@busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>

Kieran, All,

On 2019-03-19 14:12 +0000, Kieran Bingham spake thusly:
> On 19/03/2019 12:50, Yann E. MORIN wrote:
> > On 2019-03-19 11:03 +0000, Kieran Bingham spake thusly:
> >> diff --git a/DEVELOPERS b/DEVELOPERS
> >> index c91325e28486..5bcdf208a62b 100644
> >> --- a/DEVELOPERS
> >> +++ b/DEVELOPERS
> >> @@ -1260,6 +1260,9 @@ F:	package/ramsmp/
> >>  N:	Kevin Joly <kevin.joly@sensefly.com>
> >>  F:	package/libgphoto2/
> >>  
> >> +N:	Kieran Bingham <kieran.bingham@ideasonboard.com>
> >> +F:	package/libcamera/
> Is it possible to put the libcamera mailinglist as a 'cc' target here as
> well? or is it only individuals.

The problem is that libcamera-dev is subscription-based too, so people
who are not subscribed get a "pending-approval" message, which is not
very interesting...

> If someone (other than me) updates the package, It would be nice for
> that notification to go to the list.

Well, the goal of the DEVELOPERS file is that someone-not-you update the
package, they do Cc you. For example, with your patch applied, run:

    ./utils/get-developers -p libcamera

Or:

    git show |./get-developers -

which will reprt you as the person to Cc on patches touching the
libcamera package.

> > Also, as you already discovered, it's nice to pass a new package through
> > utils/test-pkg as well (and although not mandatory, it's nice to provide
> > that report after the --- line.)
> 
> I was going to ask how to do this - as it was skipping all 6, and then
> all 43 toolchains with -a. But I've worked it out, so for the benefit of
> others:

>From the manual:

    https://buildroot.org/downloads/manual/manual.html#_tips_and_tricks

    17.23.3. How to test your package

> I had to create a libcamera.config and specify the EUDEV dependency:
> 
>   BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
>   BR2_PACKAGE_LIBCAMERA=y
> 
> Then:
>  ./utils/test-pkg -c libcamera.config -p libcamera

Regards,
Yann E. MORIN.

On 19/03/2019 15:12, Kieran Bingham wrote:
> Hi Yann,
> 
> Thank you for the review,
> 
> On 19/03/2019 12:50, Yann E. MORIN wrote:
>> Kieran, All,
>>
>> On 2019-03-19 11:03 +0000, Kieran Bingham spake thusly:

[snip]
>>> +LIBCAMERA_SITE_METHOD = git
>>> +LIBCAMERA_DEPENDENCIES = udev

 Since this is a library, I'd expect _INSTALL_STAGING = YES.

>>> +LIBCAMERA_LICENSE = LGPL-2.0+
>>
>> This is not LGPL-2.0+, but LGPL-2.1+
> 
> Ugh, I should have remembered that, especially as I added the licenses...
> 
>>
>> There are actually 2 other licenses applicable to this package: GPLv2.0+
>> and CC-BY-SA-4.0 (or later?).
>>
>> We usually specify what part of the package they apply to (correct me
>> if/where I am wrong):
>>
>>     LIBCAMERA_LICENSE = LGPL-2.1+ (library), GPL-2.0+ (utils, test), CC-By_SA-4.0 (doc)

 AFAIU, we only specify licenses of stuff installed on target. Since
/usr/share/doc gets removed in target-finalize, the doc license should not be
relevant.

 BTW it would be nice if there was a meson option to disable building docs. I
don't know how it is for the libcamera doc, but doxygen and sphinx are sometimes
a bit slow.

> 
> 
> That looks accurate to me.
> 
> I've updated the patch.
> 
>>
>> Please also specify the files that contain the license texts:
>>
>>     LIBCAMERA_LICENSE_FILES = \
>>         licenses/cc-by-sa-v4.0.txt \
>>         licenses/developer-certificate-of-origin.txt \
>>         licenses/gnu-gpl-2.0.txt \
>>         licenses/gnu-lgpl-2.1.txt

 Please also add hashes for these files.

 Thanks!

 Regards,
 Arnout

Hi Arnout,

Thank you for your review too :)

On 19/03/2019 23:18, Arnout Vandecappelle wrote:
> 
> 
> On 19/03/2019 15:12, Kieran Bingham wrote:
>> Hi Yann,
>>
>> Thank you for the review,
>>
>> On 19/03/2019 12:50, Yann E. MORIN wrote:
>>> Kieran, All,
>>>
>>> On 2019-03-19 11:03 +0000, Kieran Bingham spake thusly:
> 
> [snip]
>>>> +LIBCAMERA_SITE_METHOD = git
>>>> +LIBCAMERA_DEPENDENCIES = udev
> 
>  Since this is a library, I'd expect _INSTALL_STAGING = YES.

Great, I'll add this.

>>>> +LIBCAMERA_LICENSE = LGPL-2.0+
>>>
>>> This is not LGPL-2.0+, but LGPL-2.1+
>>
>> Ugh, I should have remembered that, especially as I added the licenses...
>>
>>>
>>> There are actually 2 other licenses applicable to this package: GPLv2.0+
>>> and CC-BY-SA-4.0 (or later?).
>>>
>>> We usually specify what part of the package they apply to (correct me
>>> if/where I am wrong):
>>>
>>>     LIBCAMERA_LICENSE = LGPL-2.1+ (library), GPL-2.0+ (utils, test), CC-By_SA-4.0 (doc)
> 
>  AFAIU, we only specify licenses of stuff installed on target. Since
> /usr/share/doc gets removed in target-finalize, the doc license should not be
> relevant.

Ok, so should I just remove the CC licence?


>  BTW it would be nice if there was a meson option to disable building docs. I
> don't know how it is for the libcamera doc, but doxygen and sphinx are sometimes
> a bit slow.


I agree, - the docs won't build if sphinx /doxygen isn't found - but
when I built on my laptop in buildroot, it 'discovered' the exectuable
for sphinx, but without an install inside the buildroot environment so
it failed at first.

So a --disable-docs option is certainly going to be useful. I'll try and
get it added and included for this packaging process.


>>
>>
>> That looks accurate to me.
>>
>> I've updated the patch.
>>
>>>
>>> Please also specify the files that contain the license texts:
>>>
>>>     LIBCAMERA_LICENSE_FILES = \
>>>         licenses/cc-by-sa-v4.0.txt \
>>>         licenses/developer-certificate-of-origin.txt \
>>>         licenses/gnu-gpl-2.0.txt \
>>>         licenses/gnu-lgpl-2.1.txt
> 
>  Please also add hashes for these files.

Ack ...

Are all of these relevant actually? I wonder if I should drop the
cc-by-sa-v4.0 if I'm dropping the docs licence above, and the DCO, as
that's only really about contributing to the project?

--
Kieran



> 
>  Thanks!
> 
>  Regards,
>  Arnout
>

Kieran, All,

On 2019-03-20 09:25 +0000, Kieran Bingham spake thusly:
> On 19/03/2019 23:18, Arnout Vandecappelle wrote:
> >  AFAIU, we only specify licenses of stuff installed on target. Since
> > /usr/share/doc gets removed in target-finalize, the doc license should not be
> > relevant.
> Ok, so should I just remove the CC licence?

Yes, drop it both from the list and the files-list.

> Are all of these relevant actually? I wonder if I should drop the
> cc-by-sa-v4.0 if I'm dropping the docs licence above, and the DCO, as
> that's only really about contributing to the project?

Yes, drop the CC license and the DCO.

Regards,
Yann E. MORIN.

On 20/03/2019 10:25, Kieran Bingham wrote:
[snip]
>>>> We usually specify what part of the package they apply to (correct me
>>>> if/where I am wrong):
>>>>
>>>>     LIBCAMERA_LICENSE = LGPL-2.1+ (library), GPL-2.0+ (utils, test), CC-By_SA-4.0 (doc)
>>
>>  AFAIU, we only specify licenses of stuff installed on target. Since
>> /usr/share/doc gets removed in target-finalize, the doc license should not be
>> relevant.
> 
> Ok, so should I just remove the CC licence?

 Indeed.

>>  BTW it would be nice if there was a meson option to disable building docs. I
>> don't know how it is for the libcamera doc, but doxygen and sphinx are sometimes
>> a bit slow.
> 
> 
> I agree, - the docs won't build if sphinx /doxygen isn't found - but
> when I built on my laptop in buildroot, it 'discovered' the exectuable
> for sphinx, but without an install inside the buildroot environment so
> it failed at first.
> 
> So a --disable-docs option is certainly going to be useful. I'll try and
> get it added and included for this packaging process.

 --disable-docs? Coming from autotools, are you? :-P

 While you're at it, maybe you can add a disable for the tests as well (then you
don't need to mention them in the licenses either).


>>> That looks accurate to me.
>>>
>>> I've updated the patch.
>>>
>>>>
>>>> Please also specify the files that contain the license texts:
>>>>
>>>>     LIBCAMERA_LICENSE_FILES = \
>>>>         licenses/cc-by-sa-v4.0.txt \
>>>>         licenses/developer-certificate-of-origin.txt \
>>>>         licenses/gnu-gpl-2.0.txt \
>>>>         licenses/gnu-lgpl-2.1.txt
>>
>>  Please also add hashes for these files.
> 
> Ack ...
> 
> Are all of these relevant actually? I wonder if I should drop the
> cc-by-sa-v4.0 if I'm dropping the docs licence above, and the DCO, as
> that's only really about contributing to the project?

 Correct, only the two gpls should be relevant. For complicated license
situations a README that explains what applies to what would also be relevant,
but in this case it's not needed IMO.


 Regards,
 Arnout

Hi Yann,

On 19/03/2019 15:38, Yann E. MORIN wrote:
> Kieran, All,
> 
> On 2019-03-19 14:12 +0000, Kieran Bingham spake thusly:
>> On 19/03/2019 12:50, Yann E. MORIN wrote:
>>> On 2019-03-19 11:03 +0000, Kieran Bingham spake thusly:
>>>> diff --git a/DEVELOPERS b/DEVELOPERS
>>>> index c91325e28486..5bcdf208a62b 100644
>>>> --- a/DEVELOPERS
>>>> +++ b/DEVELOPERS
>>>> @@ -1260,6 +1260,9 @@ F:	package/ramsmp/
>>>>  N:	Kevin Joly <kevin.joly@sensefly.com>
>>>>  F:	package/libgphoto2/
>>>>  
>>>> +N:	Kieran Bingham <kieran.bingham@ideasonboard.com>
>>>> +F:	package/libcamera/
>> Is it possible to put the libcamera mailinglist as a 'cc' target here as
>> well? or is it only individuals.
> 
> The problem is that libcamera-dev is subscription-based too, so people
> who are not subscribed get a "pending-approval" message, which is not
> very interesting...

libcamera-dev is indeed a mailman instance, but we do not require a
subscription to post.

As you note, to prevent spam the first post from anyone will require
moderation - but once approved all further posts from that person will
be accepted, and the initial post does not need to be resent. It will
hit the list once approved.



>> If someone (other than me) updates the package, It would be nice for
>> that notification to go to the list.
> 
> Well, the goal of the DEVELOPERS file is that someone-not-you update the
> package, they do Cc you. For example, with your patch applied, run:
> 
>     ./utils/get-developers -p libcamera
> 
> Or:
> 
>     git show |./get-developers -
> 
> which will reprt you as the person to Cc on patches touching the
> libcamera package.

Yes, I like that :) but I might not always be the best contact for the
libcamera package, which is why I thought the list would be more
appropriate.

I can just leave the developer entry as me for now. If it ever became an
issue it could be updated easily.


>>> Also, as you already discovered, it's nice to pass a new package through
>>> utils/test-pkg as well (and although not mandatory, it's nice to provide
>>> that report after the --- line.)
>>
>> I was going to ask how to do this - as it was skipping all 6, and then
>> all 43 toolchains with -a. But I've worked it out, so for the benefit of
>> others:
> 
> From the manual:
> 
>     https://buildroot.org/downloads/manual/manual.html#_tips_and_tricks
> 
>     17.23.3. How to test your package
> 
>> I had to create a libcamera.config and specify the EUDEV dependency:
>>
>>   BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y>>   BR2_PACKAGE_LIBCAMERA=y
>>
>> Then:
>>  ./utils/test-pkg -c libcamera.config -p libcamera
> 
> Regards,
> Yann E. MORIN.
>

Hi Arnout,

On 20/03/2019 09:34, Arnout Vandecappelle wrote:
> 
> 
> On 20/03/2019 10:25, Kieran Bingham wrote:
> [snip]
>>>>> We usually specify what part of the package they apply to (correct me
>>>>> if/where I am wrong):
>>>>>
>>>>>     LIBCAMERA_LICENSE = LGPL-2.1+ (library), GPL-2.0+ (utils, test), CC-By_SA-4.0 (doc)
>>>
>>>  AFAIU, we only specify licenses of stuff installed on target. Since
>>> /usr/share/doc gets removed in target-finalize, the doc license should not be
>>> relevant.
>>
>> Ok, so should I just remove the CC licence?
> 
>  Indeed.
> 
>>>  BTW it would be nice if there was a meson option to disable building docs. I
>>> don't know how it is for the libcamera doc, but doxygen and sphinx are sometimes
>>> a bit slow.
>>
>>
>> I agree, - the docs won't build if sphinx /doxygen isn't found - but
>> when I built on my laptop in buildroot, it 'discovered' the exectuable
>> for sphinx, but without an install inside the buildroot environment so
>> it failed at first.
>>
>> So a --disable-docs option is certainly going to be useful. I'll try and
>> get it added and included for this packaging process.
> 
>  --disable-docs? Coming from autotools, are you? :-P

Yes, I've been around way too long already :D


>  While you're at it, maybe you can add a disable for the tests as well (then you
> don't need to mention them in the licenses either).

That sounds reasonable.


>>>> That looks accurate to me.
>>>>
>>>> I've updated the patch.
>>>>
>>>>>
>>>>> Please also specify the files that contain the license texts:
>>>>>
>>>>>     LIBCAMERA_LICENSE_FILES = \
>>>>>         licenses/cc-by-sa-v4.0.txt \
>>>>>         licenses/developer-certificate-of-origin.txt \
>>>>>         licenses/gnu-gpl-2.0.txt \
>>>>>         licenses/gnu-lgpl-2.1.txt
>>>
>>>  Please also add hashes for these files.
>>
>> Ack ...
>>
>> Are all of these relevant actually? I wonder if I should drop the
>> cc-by-sa-v4.0 if I'm dropping the docs licence above, and the DCO, as
>> that's only really about contributing to the project?
> 
>  Correct, only the two gpls should be relevant. For complicated license
> situations a README that explains what applies to what would also be relevant,
> but in this case it's not needed IMO.


Great, that simplifies things.

--
Kieran

Hi Yann,

On 20/03/2019 09:29, Yann E. MORIN wrote:
> Kieran, All,
> 
> On 2019-03-20 09:25 +0000, Kieran Bingham spake thusly:
>> On 19/03/2019 23:18, Arnout Vandecappelle wrote:
>>>  AFAIU, we only specify licenses of stuff installed on target. Since
>>> /usr/share/doc gets removed in target-finalize, the doc license should not be
>>> relevant.
>> Ok, so should I just remove the CC licence?
> 
> Yes, drop it both from the list and the files-list.
> 
>> Are all of these relevant actually? I wonder if I should drop the
>> cc-by-sa-v4.0 if I'm dropping the docs licence above, and the DCO, as
>> that's only really about contributing to the project?
> 
> Yes, drop the CC license and the DCO.

Ack, will do :)

Thanks again for your time. Once I get the pending libcamera patches
reviewed and integrated I'll repost a v2 and we should be nearly there :D


Thank you for your help!


> Regards,
> Yann E. MORIN.
>