[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