[Debian-on-mobile-maintainers] Fwd: Your package buffybox

[undef]

Copying the list back in so the conversation remains public.

On 1/2/26 18:28, Mechtilde Stehmann wrote:
> Hello,
>
>
> Am 02.01.26 um 03:06 schrieb undef:
>> Hi,
>>
>> On 12/31/25 20:42, Mechtilde Stehmann wrote:
>>> Hello, 
>> <snip>
>>> The problem is the content of "lvgl/docs/CONTRIBUTING.rst:220 f." 
>>> and "lvgl/LICENCE.txt" in the lvgl directory.
>>
>>
>> I've had a talk to another developer working on Mobian/Debian to try 
>> to clarify this. We both believe that the key point of confusion is 
>> that this package contains two different projects:
>
> Yes this is the reason of the problem.
>
>>
>> 1. LVGL: A vendored graphics library.
>> 2. Buffybox: The project I'm actually trying to package.>
>> As such, there are two different upstreams, with two different 
>> license policies:
>>
>> 1. LVGL: This project quite reasonably doesn't accept GPL-only code to
>>     allow the library as a whole to remain MIT.
>> 2. Buffybox: This project includes some MIT code from LVGL, but is not
>>     required to follow the contibuting guide for LVGL.
>>
>> This is made a fair bit more obvious in the upstream repo (https:// 
>> gitlab.postmarketos.org/postmarketOS/buffybox) where LVGL is a git 
>> submodule. They are packaged as a single upstream tarball simply to 
>> provide an easier experience with uscan v4.
>
> <snip />
>>>
>>> Please forward the issue to upstream with the above text "LVGL can 
>>> not accept GPL licensed code" regarding the compatibility of GPL and 
>>> MIT. Both license are used in the same package.
>>
>>
>> Because of the above description of two different upstreams, I don't 
>> believe it would be reasonable to ask LVGL to remove this comment.
>
> For different upstream projects. You have to package two different 
> packages.
>
> And each package has to describe where the upstream code is found.
>
> This makes it possible for the LVGL library to be available to other 
> projects as well.


I understand that this is the default and preferred case for Debian 
packages. However, the LVGL library doesn't support this case. The 
library cannot be built generically and dynamically linked because each 
package using in needs to reconfigure the library to suit its needs. For 
example, if Debian contained a generic LVGL with LV_LOG_PRINTF defined 
as 1 unl0kr would fail as it would print log lines into the cryptsetup 
password. See 
https://gitlab.postmarketos.org/postmarketOS/buffybox/-/commit/79c1b2dfb6c8c14bf1e75bc71f3296d3bd54f91a#2e47c74a88bb66bf5c88a7f5e55ec0f35f664026_144_143 
for the commit where that was set in Buffybox.

For this reason I have packaged Buffybox and LVGL as a single package. 
There is precident for this at a minimum in the Unl0kr package, which 
was accepted including a vendored LVGL in 2023 
(https://tracker.debian.org/pkg/unl0kr). Buffybox replaces the Unl0kr 
package.


The only alternative I am aware of is packaging LVGL as a Rust-style 
binary package containing source code. However, this is far more 
complicated and I do not believe there is any additional gain in doing 
so for the following reasons:

 1. So far as I am aware and from a cursory search of the archive, no
    other package depends on LVGL (excluding Unl0kr, which will be
    replaced by Buffybox).
 2. Being a vendored dependency, most users of LVGL expect a specific
    version. There are a significant number of commits which simply deal
    with API changes between LVGL versions where a LVGL package shared
    between multiple packages would need to be updated in lockstep,
    outside of their normal upstreams.


>
>
>>> The new DFSG team is still waiting to be able to release the package 
>>> into the Debian archive.
>>> You can use this time to clarify the aforementioned license issue 
>>> with upstream. You can also perform the update into the New Queue.
>>
>>
>> I am currently preparing a new version of the package with a few 
>> license issues ironed out and the latest upstream release. I will 
>> also include a readme.Debian file explaining the two upstreams and 
>> their relationship.
>
> This doesn't solve the problem as described above.
>
>>
>> Thanks,
>>
>> Undef.
>
> Regards


Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-on-mobile-maintainers/attachments/20260102/aac85ef8/attachment-0001.htm>