[Community] [Gta04-owner] Report on QtMoko

[H. Nikolaus Schaller]

> Am 15.06.2016 um 14:42 schrieb Josua Mayer <josua.mayer97 at gmail.com>:
> 
> 
> 
> 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.

Maybe we should try this first.

>> 
>> 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
>> 
> _______________________________________________
> Community mailing list
> Community at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.openphoenux.org