Hi,
let me answer to both mails in one...
Am 14.06.2018 um 09:55 schrieb Mr C Camacho chriscamacho@virginmedia.com:
I'd really appreciate the inclusion of .config support in the kernel and also /proc/config.gz support
I always include these in any VM experiments, so even if all I have is the binary kernel left over (at a later date), I can still recreate the kernel or use the old config to recreate a config on a newer source...
It is enabled by letux_defconfig:
root@letux:~# ls -l /proc/config.gz -r--r--r-- 1 root root 35509 Jun 14 10:10 /proc/config.gz root@letux:~#
On 14/06/18 03:26, Michael Mrozek wrote:
As we're getting closer to release, it's important in my opinion that we clean up things a bit and organize things.
As you probably saw in my last email, I don't even know where to get everything - and that should be well documented on a website (ideally on https://dev.pyra-handheld.com/ ).
I can summarize everything there, but we first need to get a good structure and make some decisions how to proceed, as (in my opinion), it's a bit of a mess right now.
Let's start with the kernel:
I'm not sure whether we use the Letux Kernel as is or whether we apply some patches (or our own config file).
Yes, there should be a different config for the PyraOS. Letux OS has a lot of stuff not needed and compiling more things into the kernel reduces boot time.
Even if we simply use a modified configuration, this needs to be available. If someone wants to compile the exact same kernel as is running on the retail unit, he also needs a changed config file.
So, the main question is: How should we handle that? Should we simply use the LETUX kernel as is?
The question is if you want to maintain it or if we simply integrate it into the letux git tree. This would make it easier for people to either make letux_defconfig or let's say make pyra_defconfig. This could help especially if there are problems.
That would easiest, however, we need to make sure we provide kernels that don't break anything serious (for example, one of the last releases broke audio - this should NEVER EVER happen if a normal user updates his system).
That is a matter of of doing enough and repeated regression testing.
What I do with the Letux kernel is to have "latest" version and a "work-in-progress" version. The "latest" one has been tested as good as possible (more testing is always possible and may reveal additional bugs). Only if the "mainline" thing has fixed known bugs, it becomes the "latest" kernel which is installed by normal users.
It is sort of beta version vs. production version. Developers sometimes have additional alpha-code on top of it.
@Nikolaus: Do we have a way to ensure this doesn't happen?
I don't have it, but we as a group can do more testing than in the past...
Is the stable-release on your kernel GIT tested properly?
Definitively NO, because there is no definition of "properly" and who is doing that.
Ideally, we would provide an unstable- or stable kernel in our OS, so every user can help with testing if he wants to.
That is how Letux OS is organised. The missing piece are enough testers, not a process or a repository or structure.
Another option would be to setup a git on our gitlab which would be basically a clone of the Letux kernel git with changes / additions that should not find their ways into the default Letux kernel.
Hm. Are there any? I see (at least at the moment) no reason or example what should not go into Letux.
This would be a bit cleaner in my opinion, as we would have everything together in our own git-repos - even if we use vanilla Letux without any changes.
Well, depends if you want to form two groups of developers "we" vs. "they" with potential issues.
BR, Nikolaus