<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Jeremiah,<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">thanks for help!</div></div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><div>If you build against embedded openGL you should be okay-ish. The various ARM graphic implementations are standardized so that graphics in general work pretty well.<br></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I guess paranoia does come out of these messages - 'okay-ish' is not exactly something like 'you'll be fine' :)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As for environment, flatpaks are built using Flathub platforms, as in <a href="https://flathub.org/builds/#/builders/32/builds/3757">https://flathub.org/builds/#/builders/32/builds/3757</a> . In this respect, I don't know details regarding the platform. But, if its all standardized, I presume it shoul dbe OK.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><div></div><div>There is no question that flatpak won't do everything. I think your use case is one area where debs will always be used, e.g. daemons. But also libraries and other lower-level middleware and tooling will benefit from being a deb I believe.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Indeed, OSM Scout Server has a daemon mode and its used most of the time for offline maps. Pure Maps, on the other hand, doesn't need to be deb as such. Its started and used via GUI only. Pure Maps is also developed quite fast these days and the faster I can publish it, the better it is.</div></div><div><br></div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div style="font-size:small">Decent amount of software is distributed via alternative channels, mainly via OpenRepos. Compared to the official store, its a proper wild west. There are no checks, developers get their personal repositories (think of it as PPAs), developers can upload whatever they wish (could be taken down for copyright reasons), and all seems to work on trust. And, in my experience, this presence of trust works quite well for Sailfish. Community is small and if you release a decent software you start to build up the trust as well. </div></div></div></div></blockquote><div><br></div><div>I think that model might not work so well for the L5. I think it should be a "trustless" system so that you don't need to have a requirement on anyone else for approval or control. Providing reproducible builds will go a long way to replacing the trust element because if you can build a byte-for-byte identical binary from source code, well you know that you can trust your supply chain.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">It helps if you can trust the supply chain. Then there is only a small question of trusting the original software - that it doesn't have any backdoors written in, for example. In this respect, you will have to make up your mind and trust the authors. And that's the part where some kind of trust by users (or distribution) is needed.</div></div><div class="gmail_default" style="font-size:small"><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div style="font-size:small">As you can imagine, I would be happy to get something like OBS for L5. How to hook it with QA procedures, that's another story. In some respect, having a documented build (if used for open-sourced project), is a good start for QA as well.<br></div></div></div></blockquote><div><br></div><div>Having the source code and being able to build it are huge for QA. :-) If you were to provide a repo I'd be more than happy to help you build a deb that we can use on the L5.</div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">I have started packaging of components and this work is all available at Github:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For Pure Maps:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="https://github.com/rinigus/deb-qmapboxgl">https://github.com/rinigus/deb-qmapboxgl</a><br></div><div class="gmail_default" style="font-size:small"><a href="https://github.com/rinigus/deb-qml-module-mapboxmap">https://github.com/rinigus/deb-qml-module-mapboxmap</a><br></div><div class="gmail_default" style="font-size:small"><a href="https://github.com/rinigus/deb-qml-module-nemo-dbus">https://github.com/rinigus/deb-qml-module-nemo-dbus</a><br></div><div class="gmail_default" style="font-size:small"><a href="https://github.com/rinigus/deb-qmlrunner">https://github.com/rinigus/deb-qmlrunner</a><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Whether to invest major time into DEB packaging of Pure Maps, that's an open question. If we don't benefit much from having it running from DEB when compared to Flatpak (either in terms of testing issues reported separately or day-to-day use), then maybe we should look into that later.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For OSM Scout Server, I haven't made any DEB scripts yet. These would have to cover </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Valhalla (as packaged in <a href="https://github.com/rinigus/pkg-valhalla-lite">https://github.com/rinigus/pkg-valhalla-lite</a>)</div><div class="gmail_default" style="font-size:small">Mapnik with my patch to support compact description of geometries in SQLite (<a href="https://github.com/rinigus/pkg-mapnik">https://github.com/rinigus/pkg-mapnik</a>)</div><div class="gmail_default" style="font-size:small">Libpostal (<a href="https://github.com/rinigus/pkg-libpostal">https://github.com/rinigus/pkg-libpostal</a>)</div><div class="gmail_default" style="font-size:small">OSM Scout Server (<a href="https://github.com/rinigus/osmscout-server">https://github.com/rinigus/osmscout-server</a>)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">At SFOS, my OBS repo is mainly OSM Scout Server dependencies and dependencies of dependencies (with exception of Mapbox GL also in the same repo). It maybe of help to see if something is missing on Debian: <a href="https://build.merproject.org/project/show/home:rinigus:maps">https://build.merproject.org/project/show/home:rinigus:maps</a> . Out f these, ZeroMQ is not used by Valhalla lite version, so those are not needed.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Assuming that we have access to Noto fonts on a system, these fonts don't need to be packaged. They are used if raster tiles are requested from the server. Pure Maps doesn't need it, but some other software may. For example, Gnome Maps is using raster tiles (but has no link yet with OSM Scout Server).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Now, a tricky part with OSM Scout Server would be to ensure that we have the compatible versions of the backends on multiple platforms. Namely, I am packaging the geo-databases and distributing them separately. Sometimes, we have to make jumps in backend libs which are incompatible. Upcoming jump will be in Valhalla, when I manage to get my hands on it. That means that I have to package the geo-databases, test it with new code; distribute all OSM Scout Server binaries for SFOS, L5, and Flathub Linux, and then switch to the geo-databases on servers. In practice, SFOS and Flathub Linux works, L5 - we have to figure pipeline for it. This pipeline should allow me to upload new version when ready, but I guess that's a part which is covered by the upcoming store.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As for packaging of the server, having the requirement of compatible libs, means that I have to bundle the libraries of these critical components with the server. I cannot rely on distribution making a change that would be set by the server. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cheers,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rinigus</div></div></div>