Re: Building unofficial packages on Alpine build infrastructure?
On Sun, Oct 29, 2017 at 10:49 AM, Jakub Jirutka <jakub_at_jirutka.cz> wrote:
>> 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.
Well, to be honest, I only responded to that thread because you
misrepresented how Adelie is structured, for reasons I still do not
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.
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’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?
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
>> 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.
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.
Received on Sun Oct 29 2017 - 21:36:44 GMT