[Community] [Gta04-owner] Report on QtMoko

Josua Mayer josua.mayer97 at gmail.com
Wed Jun 15 14:42:07 CEST 2016

Am 15.06.2016 um 14:10 schrieb H. Nikolaus Schaller:
> 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.
I see. Well that is a relieve!
>> 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_).
What I mean is simple: If:
a) the change is tested
b) you dont feel like there is a need to discuss potential alternatives
feel free to commit.
I did consider a pull-request approach, but that is really pointless as
long as there are so few people working on this tree.
>>>>>> 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,
Really? I think I have been using both 301 and 302 for this purpose in
the past.
> 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.
that seems the cleanest approach to me.
> 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
> _______________________________________________
> Community mailing list
> Community at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.openphoenux.org

More information about the Community mailing list