[Gta04-owner] [Tinkerphones] Towards QtMoko2: building QtMoko from sources

Jonas Smedegaard jonas at jones.dk
Sat Jun 3 21:30:35 CEST 2017

Quoting H. Nikolaus Schaller (2017-06-03 20:46:16)
>> Am 03.06.2017 um 19:38 schrieb Jonas Smedegaard <jonas at jones.dk>: 
>> Quoting H. Nikolaus Schaller (2017-06-03 18:18:49)
>>> b) add to /etc/apt/sources.list
>>>        deb http://www.qtmoko.net/download/ wheezy main
>>>        deb-src http://www.qtmoko.net/download/ wheezy main
>> [...]
>>> Well, there are still some limitations I want to work on in the next 
>>> weeks:
>>> * the repository has no GPG signatures so one has to work around 
>>> apt-get security complaints
>> Simplest is probably to instead use these APT lines:
>>    deb [ trusted=yes ] http://www.qtmoko.net/download/ wheezy main
>>    deb-src [ trusted=yes ] http://www.qtmoko.net/download/ wheezy main
> Simplest for the user.

No, simplest for the package maintainer - i.e. for you.

Simplest for the user is to have the packages officially part of Debian.

> Maybe I should learn how to GPG sign packages and the repository... 
> Probably the biggest issue is that I need a certificate that is 
> accepted by the Debian key ring.

Only packages officially included with Debian get certified by Debian.

You are quite welcome: https://www.debian.org/devel/join/

To release non-Debian .deb packages with some (lesser) degree of 
security, you will need to a) setup routines to sign your release files 
each time you add, update, or remove a package to your package pool, and 
b) offer a way for your users to validate that security - i.e. establish 
a trust path.

For a) the most common way is to use the tool reprepro.

For b) a common approach is to put public part of your signing keypair 
in a package of its own and tell your users to simply install that first 
- but I consider that approach flawed: You then basically ask your users 
to _insecurely_ grant you root access to each of their systems for that 
initial magic security package which (hopefully does nothing else than) 
add your certificate to on their system.

My alternative is an inelegant but more trustworthy instruction at 
http://deb.jones.dk/ - since I have signed your key you could make a 
similar but slightly more involved instruction for a key you control.

If anyone has ideas for a more user-friendly yet trustworthy approach to 
establishing a trust path to an unofficial .deb package pool, please do 
share.  I am certainly also interested to hear if anyone consider my 
approach flawed in some way.

>>> * compilation is still slow despite ccache. I should try the 200GB 
>>> card on a Pyra or OMAP5432EVM as soon as there becomes one available 
>>> for running in background
>> Another option is to compile on an ARM device with SATA interface and 
>> more memory.
> Yes, the Pyra and OMAP5EVM have both (2-4GB RAM, 8-16 times as fast 
> CPU and SATA interface). But I still need one that is not too often 
> needed for something else. And, the only spare SATA hard disk I have 
> is broken...
> So maybe someone with suche a machine can pick up my work and report 
> results.

My point was that any device supporting the same ARM sub-architecture 
(ARMv5 a.k.a. Debian "armel", or ARMv7 a.k.a. Debian "armhf") is fine - 
for those of us without powerful OMAP devices to spare for several days.

 - Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20170603/f25957da/attachment.asc>

More information about the Gta04-owner mailing list