[PureOS] PureOS Phone images

[Jeremiah C. Foster]

On Fri, 2020-08-28 at 09:18 +0200, Guido Günther wrote:
> Hi Jeremiah,
> thanks for moving things over to a more persistent media!

<smiling emoticon here>

> On Thu, Aug 27, 2020 at 10:29:04PM -0400, Jeremiah C. Foster wrote:
> > Welcome to a thread about PureOS images for our Librem 5 phone. 
> > 
> > Let's start with Guido who knows a thing or two about the Librem 5;
> > 
> > "I'd like to (slowly) start filling in enough of byzantium so we
> > can
> > build images for the phone. First candidates would be a kernel and
> > flash-kernel. We currently keep the sources at 
> > https://source.puri.sm/Librem5/flash-kernel and 
> > https://source.puri.sm/Librem5/linux-next - i just wanted to check
> > that
> > there aren't any objections when the number of packages with
> > patches
> > increases quite a bit."
> > 
> > Matthias writes;
> > "First of all, thank you for communicating this early :-) I have no
> > fundamental objections to adding it, you would just need to target
> > "byzantium" or "landing". 
> > 
> > - Any chance that the kernel changes would break the desktop flavor
> > of
> > PureOS? Or would that be a completely separate kernel package and
> > not
> > merged with the desktop kernel?
> 
> It's a separate kernel package at the moment. I don't intend to
> switch
> to Debian's kernel package until we also do that in Debian itself.
> If you look at page 25 here
> https://git.sigxcpu.org/cgit/talks/2020-debconf-mobile/plain/talk.pdf
> 
> you see that the diff is still a bit off but that will be improving
> a lot with 5.10. Also i think we'll run newer major kernel versions
> past bullseye release for some time.

So we'll need to maintain kernel packages until 5.10 is released? 

> > - You'd need to make sure phone things work on amd64 as well as on
> > arm64 in case they have a convergent base and are used on both form
> > factors. And 3) the PureOS team is tiny so we can't maintain lots
> > and
> 
> That was the plan we discusses a while back with Jeremiah. Lots of
> stuff will be adaptive with GNOME 3.38 and for GTK Sadiq worked on
> making that possible:
> 
> https://source.puri.sm/Librem5/gtk/-/merge_requests/18
> https://source.puri.sm/Librem5/gtk/-/issues/23
> 
> > lots of PureOS<->Debian delta. But with the phone team's help I
> > think
> > that's absolutely doable there's also secondary questions, like
> > whether
> > it makes sense to just move shared sources to the pureos group(s)
> > in
> > Gitlab also,

Regarding the merge to Gitlab -- we'll also need to do a "Respects Your
Freedom" application at the FSF. For this we'll need the kernel
sources, firmware, and documentation all in one place likely. It is a
lot of work to review a device like ours since it holds a lot more
software than a USB key for example. 

> >  I'll have to go through with improving Laniakea's sync
> > overview page to be less cluttered - at the moment it's quite hard
> > to
> > know what needs merging where ;-) (that's actually the thing I am
> > working on at the moment, since that also gets rid of the last bit
> > of D
> > code and makes deploying Laniakea easier).
> > 
> > - Laniakea can theoretically also build packages from Git repos -
> > you'll need a list of repos and signed tags of a certain format in
> > them, LK will then verify the tag signature and send the repo to a
> > worker to create a source package out of that's then auto-uploaded.
> > It's quite neat in concept...
> > 
> > ....in practice I would need to get rid of the manual list and
> > actually
> > verify signatures (at the moment anything would be built, so that's
> > really not deployable)
> 
> That would be cool since i'd like to phase out the route via arm02
> (which allows us to do that for the phone right now) as soon as
> possible - that's also one of the reasons we don't want to allow
> sloppy builds for byzantium.
> 
> Is there a public bug list for PureOS Infra/Laneakia that once could
> follow to learn what's planned, has been discussed?

Sort of; https://source.puri.sm/pureos/infra You'll find issues for
Laniakea here: https://source.puri.sm/pureos/infra/laniakea/-/issues

Matthias *may* prefer issues go here: 
https://github.com/lkorigin/laniakea/issues.

> 
> > Anyway, that's $future_stuff, let's work on getting the phone
> > pieces
> > into byzantium easily first :-)"
> > 
> > Jeremiah writes;
> > - I would like to understand more about the increase in kernel
> > patches;
> > how will they be maintained? What are the expectations of the
> > Librem 5
> > team, is there going to be a transfer of responsibility for the
> > patches
> > from the Librem 5 team to PureOS team?
> 
> Kernel packages are separate - kernel maintenance will be the same as
> for amber.

Okay, that sounds good. Then we'll need to ensure those who're working
on the kernel can upload new packages to Laniakea. I think this is as
simple as providing the gpg key of each person who needs to upload to
Matthias.

> > Our resources are currently thinly stretched across our CI / CD,
> > QA,
> > and support teams, which means adding devices is a heavy lift that
> > needs co-ordination. We don't really have a process for additional
> > devices yet either and there needs to be some thought as we grow
> > given
> > that our Librem 5 traffic might significantly increase load and
> > bandwidth on existing infrastructure. Do we have any data on;
> > 
> > - Currently Librem 5 CI (I believe we run Munin on the ARM 02
> > server
> > no? Do we have output from that which might show load, disk, CPU,
> > etc?
> 
> Yes. It's all rather boring load and I/O wise on arm02 since we build
> very
> few release packages. Bigger packages (gtk, mesa, kernel) take some
> disk
> but that's not different from what happens for amd64/arm64 right now.

+1

> > - How about the current instance of Laniakea? Are we running Munin?
> > If
> > not, do we have data on the server from a capacity planning
> > standpoint?
> > 
> > - I'd like to know a bit more about the plan - do we intend to use
> > your
> > new process to build from git repos with signed tags Matthias? Or
> > are
> > we going to continue to build on ARM 02 and then upload to
> > Laniakea?
> 
> For the 'mass switch' it would be very good to build from git via
> Laneakia so save maintenance and rather use arm02 as another builder
> for Laneakia (but that obviously needs Matthias involvement).

Agreed.
> 
> Regarding building from git let me add that we have done some
> prototyping to be able to restrict packages to certain maintainers
> which
> might be useful when we have more app contributors. I think taking
> the
> requirements for that into account (without blocking progress) would
> be
> good.

+1

> That said the 'where to apps go' question is one of the more
> interesting ones for
> byzantium from my PoV since we side stepped that on amber by just
> using
> amber-phone and requiring a review from a team member. This raises
> the
> following questions (not necessarily for today's meeting since that
> should (in my opinion) focus on getting convergent base in
> byzantium):
> 
> - which packaging formats do non-core apps (not necessarily
> maintained
>   by a PureOs/L5 team member) use? We use deb now. The current ones
>   are all debs https://source.puri.sm/librem5-apps and we might
>   want to continue to support that.

+1

Currently core and non-core apps are all debs. The PureOS Store when it
comes into existence will have flatpaks but I think that Matthias might
have flatpak functionality in Laniakea as well.

> - Where do uploads go? So will there be a byzantium-apps,
>   byzantium-apps-staging and maybe the same with `-sloppy` or `-
> preview`
>   for not yet perfect apps? (orthogonal to the packaging format)
>   or should that be more like Ubuntu's PPAs (which i'm not a fan of
>   for this purpose)

> - In case of Debian package: how are we preventing people to upload
>   a patched glibc there?

You have to be in the PureOS keyring which Matthias maintains.

> - How (and by whom) are permissions managed? (somewhat orthogonal to
> the
>   packaging format)

See above.

> - How is security support for these handled? (at least removal should
> be
>   triggered on known CVEs) (orthogonal to the packaging format)

A review of Debian's process indicates we might be able to lift their
process into ours and use their tool. There would still be the need for
a team however for anything that is not in Debian.

> - what is the policy for being allowed to upload an app, how is that
>   being enforced. For librem5-apps we've been basically following
>   DFSG and l5 dev policy (
> https://storage.puri.sm/librem5/l5-policy/html/) 

I can't view that URL. 

> 
> Since we have same apps at https://source.puri.sm/librem5-apps we
> could
> likely use one to testdrive this.

+1

Regards,

Jeremiah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20200901/35a2c4fd/attachment.sig>