<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Copying the list back in so the conversation remains public.</p>
<div class="moz-cite-prefix">On 1/2/26 18:28, Mechtilde Stehmann
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d422d7e8-aa49-40db-988f-56862c20dd65@debian.org">Hello,
<br>
<br>
<br>
Am 02.01.26 um 03:06 schrieb undef:
<br>
<blockquote type="cite">Hi,
<br>
<br>
On 12/31/25 20:42, Mechtilde Stehmann wrote:
<br>
<blockquote type="cite">Hello, </blockquote>
<snip>
<br>
<blockquote type="cite">The problem is the content of
"lvgl/docs/CONTRIBUTING.rst:220 f." and "lvgl/LICENCE.txt" in
the lvgl directory.
<br>
</blockquote>
<br>
<br>
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:
<br>
</blockquote>
<br>
Yes this is the reason of the problem.
<br>
<br>
<blockquote type="cite">
<br>
1. LVGL: A vendored graphics library.
<br>
2. Buffybox: The project I'm actually trying to package.>
<br>
As such, there are two different upstreams, with two different
license policies:
<br>
<br>
1. LVGL: This project quite reasonably doesn't accept GPL-only
code to
<br>
allow the library as a whole to remain MIT.
<br>
2. Buffybox: This project includes some MIT code from LVGL, but
is not
<br>
required to follow the contibuting guide for LVGL.
<br>
<br>
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.
<br>
</blockquote>
<br>
<snip />
<br>
<blockquote type="cite">
<blockquote type="cite">
<br>
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.
<br>
</blockquote>
<br>
<br>
Because of the above description of two different upstreams, I
don't believe it would be reasonable to ask LVGL to remove this
comment.
<br>
</blockquote>
<br>
For different upstream projects. You have to package two different
packages.
<br>
<br>
And each package has to describe where the upstream code is found.
<br>
<br>
This makes it possible for the LVGL library to be available to
other projects as well. <br>
</blockquote>
<p><br>
</p>
<p>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
<a class="moz-txt-link-freetext" href="https://gitlab.postmarketos.org/postmarketOS/buffybox/-/commit/79c1b2dfb6c8c14bf1e75bc71f3296d3bd54f91a#2e47c74a88bb66bf5c88a7f5e55ec0f35f664026_144_143">https://gitlab.postmarketos.org/postmarketOS/buffybox/-/commit/79c1b2dfb6c8c14bf1e75bc71f3296d3bd54f91a#2e47c74a88bb66bf5c88a7f5e55ec0f35f664026_144_143</a>
for the commit where that was set in Buffybox. </p>
<p>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
(<a class="moz-txt-link-freetext" href="https://tracker.debian.org/pkg/unl0kr">https://tracker.debian.org/pkg/unl0kr</a>). Buffybox replaces the
Unl0kr package.</p>
<p><br>
</p>
<p>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:</p>
<ol>
<li>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).</li>
<li>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.</li>
</ol>
<p><br>
</p>
<blockquote type="cite"
cite="mid:d422d7e8-aa49-40db-988f-56862c20dd65@debian.org"><br>
<br>
<blockquote type="cite">
<blockquote type="cite">The new DFSG team is still waiting to be
able to release the package into the Debian archive.
<br>
You can use this time to clarify the aforementioned license
issue with upstream. You can also perform the update into the
New Queue.
<br>
</blockquote>
<br>
<br>
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.
<br>
</blockquote>
<br>
This doesn't solve the problem as described above.
<br>
<br>
<blockquote type="cite">
<br>
Thanks,
<br>
<br>
Undef.
<br>
</blockquote>
<br>
Regards <br>
</blockquote>
<p><br>
</p>
<p>Thanks.</p>
</body>
</html>