MIME-Version: 1.0
In-Reply-To: <E85E0CFC-6981-4882-95F4-3F14168E7B78@jirutka.cz>
References: <514355cb-b6f1-c220-99fc-b096dcb0b693@bitmessage.ch>
 <CA+T2pCFsduoT_cX5K=5Ngv-B0Ko2-0iViSS0VPo=WC9FykhJQw@mail.gmail.com>
 <55293c01-cd18-19c0-1380-b0ce96a146d0@bitmessage.ch> <E85E0CFC-6981-4882-95F4-3F14168E7B78@jirutka.cz>
From: William Pitcock <nenolod@dereferenced.org>
Date: Sun, 29 Oct 2017 21:36:44 -0500
Message-ID: <CA+T2pCHdC4ZrpZ4FPQm6DQa9m6XMA7a6FFTKVEi19eb1CH8hDw@mail.gmail.com>
Subject: Re: Building unofficial packages on Alpine build infrastructure?
To: Jakub Jirutka <jakub@jirutka.cz>
Cc: Oliver Smith <ollieparanoid@bitmessage.ch>, alpine-infra@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, Oct 29, 2017 at 10:49 AM, Jakub Jirutka <jakub@jirutka.cz> wrote:
> Hi
>
>> From what I have learned from various comments on our project is, that t=
he people who say =E2=80=9Ebut it does not make calls yet=E2=80=9C would be=
 the same ones who say "but it doesn't have a UI yet" and then go on with j=
okes about making phone calls with emacs and what not=E2=80=A6
>
> Exactly my thoughts! I think that I=E2=80=99m not the only one who consid=
er this comment quite unfair from William. Actually most of his response wa=
s more or less about questioning postmarketOS=E2=80=A6 But I don=E2=80=99t =
have much information about it, so maybe it was valid, I can=E2=80=99t judg=
e. What changed my mind was not his response, but only Awilfox=E2=80=99s; s=
he works for William, but unlike him she provided very comprehensive techni=
cal arguments.

Well, to be honest, I only responded to that thread because you
misrepresented how Adelie is structured, for reasons I still do not
understand.
Maybe you would like to explain to us why you decided to bring Adelie
(the company) into that discussion, because to me, it looked like you
were trying to sabotage our efforts.

Anyway.

My doubt is in providing technical resources and personnel to a
project that may very well not be around 6 months from now.
Doing hacks to quickly implement infrastructure for a project that has
an unknown future (due to not actually being usable for daily use on
any device) takes away opportunity to properly solve these problems.
Surely you would agree with this?

To be clear, I don't really have any position on pmOS either way.
I just doubt the longterm viability of the project given what I have
seen so far.
And since I doubt the longterm viability, I am not in favour of giving
them special treatment.
Once rootbld and the other infrastructure changes are done *and the
infra team evaluates their requirements* then there is maybe something
we can do.
Which is what I said about it to begin with -- at no time did I imply
we could do that immediately.

> Anyway, I=E2=80=99d like to add this: It may seem that =E2=80=9Cmaking a =
phone call=E2=80=9D is the most important feature on mobile phones, but tha=
t=E2=80=99s not exactly right nowadays, is it? Many people, including me, w=
ould be very happy to have mobile device running Alpine with working networ=
k stack just to use it as PDA and don=E2=80=99t mind carrying good old so-c=
alled =E2=80=9Cstupid=E2=80=9D phone just for calling (or maybe use some ap=
p for calls). We can=E2=80=99t say the same about missing GUI. Since CLI is=
 unusable on todays so-called =E2=80=9Csmart=E2=80=9D phones due to missing=
 keyboard, mobile device without GUI would be totally useless for users. (N=
ote: Of course I know that software should be built from bottom to up, that=
=E2=80=99s not the point here.)
>
> Do you really need the latest KDE version, i.e. LTS version is not usable=
 for postmarketOS? In that case I=E2=80=99d suggest to take abuilds from Ad=
=C3=A9lie Linux, update them to the latest version / merge with yours, and =
maintain your own aports repository with these packages. Running aports rep=
ository itself is quite simple.
>
>> The idea is to use abuild *on the phone* to download and verify the blob=
s and build the firmware package, then install that cleanly with apk.
>
> Why? Alpine is a binary distribution, packages should be built on builder=
s, not end-user machines. It looks quite odd for me to build packages right=
 on the *phone* (and I used Gentoo for 5 years, still building pkgs on a ph=
one doesn=E2=80=99t look like a good idea for me). Why you can=E2=80=99t do=
wnload and verify these blobs on builders, package them as signed apk packa=
ges and use just apk on a phone to install them?

They can't do that because the binary firmware blobs do not meet
Alpine's licensing guidelines.
Notably, Qualcomm explicitly forbid redistribution of their firmware.
Even if we were building packages for them, I do not believe that the
infrastructure team is interested in hosting repositories that contain
packages, or building packages which violate Alpine's licensing
guidelines.

>> So I=E2=80=99ve tried to politely ask with this post if Alpine would lik=
e to build postmarketOS packages, or not (which is answered now).
>
> I have some x86_64 24-cores 64 GiB RAM machine which I can possible provi=
de you for building packages. Unfortunately I don=E2=80=99t have any physic=
al aarch64 and armhf machines. But we might try to run it with QEMU emulati=
on; it will be slow, but better than nothing.
> I=E2=80=99ll ask some people if I can get some aarch64 machine.

The builds need to run on real hardware so testsuites run on real hardware.
They have contributed qemu-based builds in the past where the
testsuite and package itself failed to run on real hardware, but
worked on qemu.
Qemu is too permissive to run testsuites on, due to playing loose with
what causes segfaults, etc.

William