Mail archive
alpine-infra

Re: Building unofficial packages on Alpine build infrastructure?

From: Jakub Jirutka <jakub_at_jirutka.cz>
Date: Sun, 29 Oct 2017 16:49:05 +0100

Hi

> From what I have learned from various comments on our project is, that the people who say „but it does not make calls yet“ would be the same ones who say "but it doesn't have a UI yet" and then go on with jokes about making phone calls with emacs and what not…

Exactly my thoughts! I think that I’m not the only one who consider this comment quite unfair from William. Actually most of his response was more or less about questioning postmarketOS… But I don’t have much information about it, so maybe it was valid, I can’t judge. What changed my mind was not his response, but only Awilfox’s; she works for William, but unlike him she provided very comprehensive technical arguments.

Anyway, I’d like to add this: It may seem that “making a phone call” is the most important feature on mobile phones, but that’s not exactly right nowadays, is it? Many people, including me, would be very happy to have mobile device running Alpine with working network stack just to use it as PDA and don’t mind carrying good old so-called “stupid” phone just for calling (or maybe use some app for calls). We can’t say the same about missing GUI. Since CLI is unusable on todays so-called “smart” phones due to missing keyboard, mobile device without GUI would be totally useless for users. (Note: Of course I know that software should be built from bottom to up, that’s 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’d suggest to take abuilds from Adélie Linux, update them to the latest version / merge with yours, and maintain your own aports repository with these packages. Running aports repository itself is quite simple.

> The idea is to use abuild *on the phone* to download and verify the blobs and build the firmware package, then install that cleanly with apk.

Why? Alpine is a binary distribution, packages should be built on builders, 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 phone doesn’t look like a good idea for me). Why you can’t download and verify these blobs on builders, package them as signed apk packages and use just apk on a phone to install them?

> So I’ve tried to politely ask with this post if Alpine would like 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 provide you for building packages. Unfortunately I don’t have any physical aarch64 and armhf machines. But we might try to run it with QEMU emulation; it will be slow, but better than nothing.
I’ll ask some people if I can get some aarch64 machine.

Jakub

> On 29. Oct 2017, at 13:27, Oliver Smith <ollieparanoid_at_bitmessage.ch> wrote:
>
>> why a phone OS distribution is concentrating on KDE when they haven't even managed to check off the "makes phone calls" tickbox yet.
>
> From what I have learned from various comments on our project is, that the people who say "but it does not make calls yet" would be the same ones who say "but it doesn't have a UI yet" and then go on with jokes about making phone calls with emacs and what not (which I do find pretty funny). postmarketOS is far from ready for being a daily driver and we're trying to be upfront with that basically everywhere (on the homepage, in every blog post, in github, in the wiki, ... - suggestions on how we can improve that are welcome).
>
> There are people working on the plasma stack, because that is what interests them. I don't see any point in saying: "No, everyone must work on the telephony stack first." Personally I try support all efforts that bring the project forward, in one direction or another (tablets and using old phones as raspberry pis with sensors built in are fine use cases as well, that can also save the devices from being useless and thrown away). And I'm trying to see where we are blocked and push in that direction so we can move forward.
>
> A binary repository is one of them, it would make the life of all contributors much easier (some contributors don't have access to fast CPUs and compiling kernels already takes hours for them), that's why I'd like to have a solution for that rather sooner than later.
>
> So I've tried to politely ask with this post if Alpine would like to build postmarketOS packages, or not (which is answered now). And also only because making this possible was suggested by Alpine developers in the first place, I would not have asked otherwise.
>
>> At least, any firmware I would be loading into my phone, I would want
>> to be delivered to me in a signed package, not downloaded at install
>> time.
>
> The idea is to use abuild *on the phone* to download and verify the blobs and build the firmware package, then install that cleanly with apk. If you are interested in this topic and have the time to spare, I would be happy if you reviewed the idea in the GitHub issue (also regarding Alpine policy and how we could make it conform to that).
>
> Best regards,
> Oliver
>
>
> William Pitcock:
>> Hi,
>>
>> On Tue, Oct 24, 2017 at 5:47 PM, Oliver Smith
>> <ollieparanoid_at_bitmessage.ch> wrote:
>>> Dear Alpinists,
>>>
>>>
>>> at least Timo Teras[1] and William Pitcock[2] have proposed, that the
>>> Alpine package building infrastructure could be used for unofficial
>>> Alpine packages, when "the new build infrastructure [is] in place".
>>
>> Yes, I have indeed proposed this.
>> But the new build infrastructure is not yet in place.
>>
>>> So postmarketOS[3] is a thin layer on top of Alpine, that provides
>>> packages to make it work on mobile devices. Currently every user is
>>> compiling these from source, but we would be very grateful if we could
>>> use Alpine's infrastructure for building binary packages. That way we
>>> could focus more on actual development and giving back to Alpine (e.g.
>>> together with Adélie, we're currently upstreaming KDE), instead of
>>> duplicating the effort.
>>
>> I proposed that we (Adelie and pmOS) might work together, but
>> unfortunately our requirements are incompatible (LTS vs. non-LTS
>> KDE).[1]
>>
>>> For reference, here[4] are our current aports. Especially the device
>>> folder makes no sense to be upstreamed. We will not build packages that
>>> contain closed source blobs (our firmware aports will be refactored to
>>> download these files at installation time[5]).
>>>
>>> Thoughts?
>>
>> Well, I mean, I don't want to tell you what to do, but it seems
>> foolish to use a package manager which can cryptographically verify
>> package contents just to download a script which downloads the real
>> files.
>> At least, any firmware I would be loading into my phone, I would want
>> to be delivered to me in a signed package, not downloaded at install
>> time.
>> Not to mention that packages which download files in their
>> post-install scripts are a violation of Alpine policy.
>>
>> William
>>
>> [1]: Since we're using footnotes, I might ponder out loud why a phone
>> OS distribution is concentrating on KDE when they haven't even managed
>> to check off the "makes phone calls" tickbox yet.[2]
>> [2]: While I am not involved in sysadmin tasks around here, I am
>> pretty sure that any such collaboration on buildserver usage would be
>> dependent on the derivative proving it's viability first. See also
>> checking off the "makes phone calls" tickbox.
>>
>


Received on Sun Oct 29 2017 - 16:49:05 GMT