
<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>On Sat, 2019-05-25 at 00:21 +0300, rinigus via Librem-5-dev wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 24, 2019 at 10:44 PM David Boddie via Librem-5-dev <<a href="mailto:librem-5-dev@lists.community.puri.sm">librem-5-dev@lists.community.puri.sm</a>> wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">On Fri, 24 May 2019 20:57:11 +0300, rinigus wrote:<br>

<br>

> while Flatpak would probably work for most of the applications, we may need<br>

> once in a while to build applications with DEBs for L5. Examples include<br>

> testing, distribution of applications that are not matching Flatpak<br>

> restrictions, and maybe some other reasons. Right now, I am looking for it<br>

> to be able to distribute maps software for testing and distinguish issues<br>

> coming from flatpak packaging - something I cannot rule out.<br>

<br>

What kind of issues are you thinking of?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Its probably paranoia, but the thought is as follows. Flatpaks are build using some configuration settings - in my case at Flathub - that may not reflect fully hardware on which they run. In particular, I don't know how much of hardware-specific libs are used in such components like graphical stack (hw acceleration, for example). On PCs, we do have these nvidia flatpak packages, for example. On ARM, I don't know how much we do and how well L5 devkit is matched. But it maybe paranoia on my side induced by a lack of knowledge.</div></div></div></div></blockquote><div><br></div><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. </div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As for other reasons for DEBs (daemons, probably some other cases), there are probably several cases where flatpak is just not the best way for approaching it.</div></div></div></blockquote><div><br></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><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">> I wonder whether we have any kind of build system that can be used now for<br>

> building "extra" deb packages that could run on L5/devkit? For Sailfish, we<br>

> have OBS that allows to compile complicated projects and distribute them<br>

> through its internal repositories.<br>

<br>

I don't know much about the Sailfish ecosystem, though I have heard of OBS.<br>

What kind of QA procedure is in place around this distribution system to<br>

ensure that the packages that get built are trusted? Do they become officially<br>

"blessed" packages, or is it just a convenient way of running the package<br>

building process to make third party packages for unofficial distribution or<br>

sideloading, like Personal Package Archives (PPA) with Ubuntu?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Good questions and there are things to learn from SFOS. On my side, I know very little about PPA (from developer's side) and had to look up how it works for developers. But let me reply to the questions one by one.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">On SFOS, there is an official store and packages in that store are blessed. The most of the restrictions are formulated via APIs that are allowed in the store. These APIs are checked for automatically when you upload your app. Next, app is checked manually by some officials in the store and only then released. What is done by that official and what is exactly is checked, I don't know. If something fails, you are told about it and you can resubmit new version. Such scheme works for closed- and open-sourced software and all work is done on compiled versions - whether by OBS or using SDK on PC.</div></div></div></div></blockquote><div><br></div><div>In both cases I believe that Sailfish is using binary blobs and/or proprietary code and build systems. At least that was the case when Sailfish was Maemo. As Maemo's debmaster I remember well struggling to get various build tools released which was very difficult. I think that is still the case that Sailfish is not really open. OBS explicitly allows this kind of thing.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" 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><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail_default" style="font-size:small">Now OBS is very handy when you have to do something complicated and, in a way, it can be used to give some credibility to your packages and repositories. For mapping software, with large amount of components, its way easier to make your own repository and build the end-product that relies on some exotic libraries. In my case, its <a href="https://build.merproject.org/project/show/home:rinigus:maps">https://build.merproject.org/project/show/home:rinigus:maps</a> . If I change any of the packages, I can easily initiate rebuild as required to get the final result for different architectures and Sailfish versions. From PPA description, it seems to be similar to OBS. In practice, OBS is used by applications that are relatively complicated, by ports of SFOS to unofficial devices, and for extending / testing the core OS components. </div></div></div></div><div dir="ltr"><div class="gmail_quote"><div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" 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.</div></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><br></div><div>Cheers,</div><div><br></div><div>Jeremiah</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail_default" style="font-size:small">Sorry for long post.</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><br></div><div> </div></div></div>

<pre>_______________________________________________</pre><pre>Librem-5-dev mailing list</pre><a href="mailto:Librem-5-dev@lists.community.puri.sm"><pre>Librem-5-dev@lists.community.puri.sm</pre></a><pre><br></pre><a href="https://lists.community.puri.sm/listinfo/librem-5-dev"><pre>https://lists.community.puri.sm/listinfo/librem-5-dev</pre></a><pre><br></pre></blockquote></body></html>