[Community] [Gta04-owner] Report on QtMoko

H. Nikolaus Schaller hns at goldelico.com
Wed Jun 15 14:10:34 CEST 2016


Hi,

> Am 15.06.2016 um 13:48 schrieb Jonas Smedegaard <dr at jones.dk>:
> 
> Quoting Josua Mayer (2016-06-15 13:07:56)
>> Am 15.06.2016 um 06:45 schrieb H. Nikolaus Schaller:
>>> Am 15.06.2016 um 00:33 schrieb Jonas Smedegaard <dr at jones.dk>:
>>>> Quoting Josua Mayer (2016-06-14 16:41:23)
>>>>> I intended to make actual debs available, but I have yet to find
>>>>> time uploading these huge things. For the moment packages will have
>>>>> to be built from source, as to the instructions in the new
>>>>> repositories linkd below.
>>>>> 
>>>>> 1) Kernel: http://projects.goldelico.com/p/qtmoko2-kernel/page/README/
>>>> 
>>>> Seems to me a more appropriate name would be gta04-kernel.
>>> 
>>> Well, "gta04-kernel" already exists and is the project for the kernel
>>> source. But it should be renamed to Letux kernel (which is the
>>> official project name).
>>> 
>>> And we have to keep in mind that kernel is not only for the gta04
>>> device but also for others like openpandora and pyra (just by picking
>>> a different device tree file). I don't know if you want to have 10
>>> slightly different kernel packages for 10 devices or a single one
>>> that runs on all (just having different u-boot setup). The latter is
>>> what we use for some time for LXDE/XFCE and Replicant and I do not
>>> see a need to go back.
>>> 
>>> On the other hand I agree that qtmoko2-kernel is also not exactly
>>> right.
>>> 
>>> A better name could be debian-kernel but that is also wrong.
>>> 
>>> The best description would be some abbreviation of:
>>> 
>>> kernel-for-letux-project-for-many-devices-but-not-all-packaged-for-debian
> 
> Ok, so scope is the whole _family_ of Letux devices, not (the GTA04
> board of) Letux 2604 as I thought.
> 
> Then the in my opinion most appropriate name is letux-kernel.
> 
> 
>>>>> There is now an easy way to build a kernel deb from whatever
>>>>> release our kernel hackers deem stable. It is meant to be unpacked
>>>>> on top of a fresh rootfs.
>>>> 
>>>> Great!
>>>> 
>>>> I have improvements - at first to the README, to use only pure
>>>> Debian, not need the (derivative of Debian) emdebian, but I may
>>>> stumble upon other details I can polish.
>> If you have good instructions for that, sure. I thought emdebian was
>> still required to get the prebuilt cross-compiler.
> 
> Emdebian is needed only with Jessie, not Stretch onwards.
> 
> Assuming your end goal is inclusion in _Debian_ I would change the
> documentation to talk about pure Debian by default now that is possible,
> and mention workaround for Jessie and older only as a comments, to
> clearly discourage use of that moving forward, and ease later cleanup.
> 
> 
>>>> Can I please get write access to that repo, or should I rather post my
>>>> proposed changes here for screening/discussion/whatever?
>>> 
>>> You already should have...
>> I believe this depends on how ripe your improvements are. At some
>> point they are bound to hit me on the head, and this is when you
>> should just commit them imo.
> 
> Not sure what you mean by that.  To be on the safe side I will *not*
> touch that git until clarified that you consider it a help that I do so.
> (but since mailinglist discussion is more tedious than git edits, I will
> likely contribute _less_).
> 
> 
>>>>> Thats it for now, as mentioned above you can expect an apt
>>>>> repository to be made available soon(TM).
>>>> 
>>>> As I mentioned also at our meeting, I would be happy to either host
>>>> that APT repo or help set it up, if that is of interest.
>> I have no objections here, whichever is easiest to upload either
>> source- or binary packages to I guess.
>>> 
>>> Since I am not sure how easy it is to set up write access for an apt
>>> repo on the goldelico server (this is outside of the project
>>> management tool), it would be a good idea to host it where the
>>> infrastructure exists.
>>> 
>>> Some things to think about:
>>> * a different server needs to manage developer login twice
>>> * ideally users would add some www.qtmoko.net path to /etc/apt/source.list
>>> * so we need to add a forwarding link
> 
> APT does not support http 301/302 redirection,

Hm. That is bad luck ...

> so if branding is important,

yes I think it is important. Small plants need a well defined home to keep
all parts together.

if we have a qtmoko.net home page downloads should come from the
same domain (until they are some day part of ftp.debian.org).

> then either services need to be established at your own hosts
> or "forwarding" means entries in domain name system.

Well, I can create a subdomain debian.qtmoko.net and direct it to
whatever IP address the server is sitting on.

At least in theory.

In practice the qtmoko domains are hosted in a package that does
not allow subdomains - but it can (an IMHO should) be changed
(by paying some one-time transfer fee...).

> 
> Most elegant setup involves root access (involves juggling low-port
> services, cron jobs, and installation of tools).  Can I be granted root
> on your server

No. There are other confidential projects running on the same server.
This is why I thought to run it on a different server and just redirect the
domain.

> to set it up, or do I need to proxy all changes through
> someone else (read: more bothersome)?

Well, that might still be easier than all other setups.

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/community/attachments/20160615/1936eb83/attachment.asc>


More information about the Community mailing list