[Librem-5-dev] applications using native debs

[rinigus]

Hi Heather, Hi List,

I have composed a set of repositories that should correspond to Debian
packaging as far as I understood.

Anyway, we have some issues, as reported by David, with running Pure Maps
on Devkit. In particular, the maps don't show up when using Pure Maps from
Flatpak. Maps do show up on QEMU image, though. Hence, there is a suspicion
on whether it is related to some hardware driver issue. For further
testing, it would be great to get Pure Maps dependencies compiled for
Devkit and simply available for anyone wishing to test further. Right now,
its simple to test with Flatpak, but I am not sure its easy to debug it in
this case.

In the respect of testing, it would be great to get

https://github.com/rinigus/deb-qmapboxgl
https://github.com/rinigus/deb-qml-module-mapboxmap

incorporated into the image.

Out of these, QMapboxGL has some background in terms of license. In
particular, one of the included 3rd party sources (rapidjson) had tests
originating from JSON.org covered by JSON license. In Qt version of the
library, that library is not used. Also, its mentioned in MapboxGL LICENSE
(originating section from rapidjson) that this license is related to the
test code only and if we don't use that, we can drop it. Right now,
MapboxGL plugin is not included in Debian due to JSON license (was assessed
in 2017, maybe it was different then or misinterpreted), large size, and
dependencies bundled with the code. Right now, when I asked and discussed
the state on Debian Qt KDE list, the license issue is not there anymore and
its mainly down to the absence of maintainer. Corresponding summary and the
issue are at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929842 , see
also links to mailing list messages in the bottom. I have also asked for
incorporation of MapboxGL as a part of QtLocation on PureOS (
https://tracker.pureos.net/T780).

QMapboxGL as packaged by me, is Qt branch of MapboxGL. Deb package is
currently based on the version that I use for Sailfish with my changes
applied on Sailfish (workarounds for Qt bugs on that platform) reversed to
pure Qt version. Now thinking about it, I should probably make a clean copy
of the upstream Qt branch and patch that. So, one more TODO in my list.  In
future, I plan to switch to the master branch since the Qt one is not
updated that well. In terms of time, we are talking about 1-2 months, but
maybe less. When that will be done, I will come up with a new package
scripts as well.

The second package - Mapbox GL QML bindings - is based on older code from
Mapbox, Qt plugin code, and my code developed to make it easy to build maps
applications using Mapbox GL. In practice it works well and has some
advantages when compared to official QtLocation plugin system.

Coming back to the test builds - ideally it would be great to have (at
least temporary) builds of qmapboxgl and qml-module-mapboxmap. In addition,
for permanent change, I would suggest to get Mapbox GL enabled in
QtLocation build. But that we can discuss in https://tracker.pureos.net/T780,
I guess.

If these additions are acceptable in terms of your policy, I will redo
QMapboxGL package using upstream code and will ping regarding the
inclusions.

Finally, if someone can check whether the debian/* are done as they
should...

Cheers and sorry for long email,

Rinigus



On Tue, May 28, 2019 at 11:10 PM Heather Ellsworth via Librem-5-dev <
librem-5-dev at lists.community.puri.sm> wrote:

> Hi Rinigus,
>
> On 5/25/19 2:05 AM, rinigus via Librem-5-dev wrote:
> > Heather,
> >
> > thank you very much! I will look into it, probably its a way to do that.
> > When comparing the build times in that monitor to the build times of the
> > maps related software, I have few packages that may need about 2 hours
> > to compile for arm. So, would be great to test it first before plugging
> > it into your system.
>
> Yep that sounds good.
>
> > In general, I will have to learn how to package for Debian and it would
> > be great to test it on some CI system before plugging it into your
> > builds. Suggestions for CI systems allowing to build private repos with
> > packages depending on each other are appreciated. So far, looks like
> > Ubuntu's PPAs would fit the bill, but maybe there is something else as
> > well.
>
> For CI systems, I'm no expert and I've really only used Jenkins. Not
> sure how difficult it would be to setup a Jenkins server somewhere, but
> their documentation in general is pretty good:
>
> https://jenkins.io/doc/book/installing/
>
> However, I wonder if you really need to take this tangent path of
> setting up and using a personal CI first before plugging it into ours. I
> think if you just get the debian packaging going, then you can add it to
> our jobs.
>
> > I am sure there lots of resources on how to package for Debian, those I
> > hope to look up myself.
>
> Here is a tutorial that looks really thourough (and quite recent too,
> which is a bonus!):
>
>
> https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf
>
> >
> > Cheers,
> >
> > Rinigus
>
> Cheers,
> Heather
>
> _______________________________________________
> Librem-5-dev mailing list
> Librem-5-dev at lists.community.puri.sm
> https://lists.community.puri.sm/listinfo/librem-5-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.community.puri.sm/pipermail/librem-5-dev/attachments/20190603/1b3c1e8a/attachment.html>