* Summary of kernel-devsrc package issues (Sumo)
@ 2018-06-04 9:04 Bas Mevissen
2018-06-04 11:32 ` Alexander Kanavin
2018-06-04 12:32 ` Bruce Ashfield
0 siblings, 2 replies; 5+ messages in thread
From: Bas Mevissen @ 2018-06-04 9:04 UTC (permalink / raw)
To: Openembedded Core
Hi all,
I ran into several issues with kernel-devsrc when building Poky Sumu
with the meta-freescale layer for an Freescale i.mx6sx ARM board. In
this mail(thread) I would like to collect them all and discuss the
possible options to resolve them.
* Install dependency issues (both during image creation and manual
install on the board):
The kernel-devsrc spec file defines a number of auto-generated run-time
dependencies. These include
(1) /bin/awk
(2) /usr/bin/python
(1) is due to scripts/ver_linux being an awk script using /bin/awk in
its shebang in various (vendor) kernels, even recent ones. Instead of
fixing all those kernel sources, I would suggest:
1a) adding a link to /bin/awk in the awk or the kernel-devsrc package
1b) automatically fix the kernel source included in the kernel-devsrc
package
1c) having a more helpful error message?
(2) is normally fine, but on my build, there is only /usr/bin/python3. A
manually created symlink fixed the issue. I'm wondering what a more
permanent solution would be:
2a) Fix all Python script in the installed kernel source like 1b)? (the
python3-native package does create such a symlink, but not the target
one!)
2b) See whether there is a package that already creates that symlink and
make kernel-devsrc depend on it?
* External module build issue:
When building an external module (rtl8812au driver) on the board using
kernel-devsrc, I ran into the following issues:
(3) No symlink from /lib/modules/`uname -r`/build to the kernel source.
Solution:
3a) Add this symlink (and optionally "source") to kernel-devsrc,
comparable to Fedora kernel-headers package
(4) The scripts where not build, resulting in build error. Solution:
4b) Pre-build scripts ("make scripts") in kernel-devsrc. Should be ok,
as the package is already arch dependent.
(remarkably, there is mention of both in the kernel-devsrc.bb file, but
I think the current solutions are wrong as the package is not
ready-to-use currently)
* Multiple kernel support:
When developing, multiple kernel versions might be installed. Current
version of the package installs in /usr/src/kernel without the kver in
the patch.
(5) So you can have only 1 set of kernel sources installed. Proposal:
(5a) Install in /usr/src/kernels/`uname r` following the way Fedora does
it.
* Huge size of package
(6) The package contains an awful lot of files and is huge. Not all of
them are needed to compile external kernel modules
6a) Remove the sources and only provide what is needed to build external
kernel modules (like fedora)
6b) Create the package suggested at 6a) (or add it to kernel-dev) and
keep the devsrc as the full-source alternative.
Your thoughts? I'm more than happy to fix the issues and provide
patches. However, I need input on what direction to go on the issues I
ran into until now.
Thanks,
Bas.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Summary of kernel-devsrc package issues (Sumo)
2018-06-04 9:04 Summary of kernel-devsrc package issues (Sumo) Bas Mevissen
@ 2018-06-04 11:32 ` Alexander Kanavin
2018-06-04 13:23 ` Bas Mevissen
2018-06-04 12:32 ` Bruce Ashfield
1 sibling, 1 reply; 5+ messages in thread
From: Alexander Kanavin @ 2018-06-04 11:32 UTC (permalink / raw)
To: Bas Mevissen, Openembedded Core
On 06/04/2018 12:04 PM, Bas Mevissen wrote:
> I ran into several issues with kernel-devsrc when building Poky Sumu
> with the meta-freescale layer for an Freescale i.mx6sx ARM board. In
> this mail(thread) I would like to collect them all and discuss the
> possible options to resolve them.
This is probably better discussed here:
https://lists.yoctoproject.org/listinfo/linux-yocto
Alex
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Summary of kernel-devsrc package issues (Sumo)
2018-06-04 11:32 ` Alexander Kanavin
@ 2018-06-04 13:23 ` Bas Mevissen
0 siblings, 0 replies; 5+ messages in thread
From: Bas Mevissen @ 2018-06-04 13:23 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: Openembedded Core
On 2018-06-04 13:32, Alexander Kanavin wrote:
> On 06/04/2018 12:04 PM, Bas Mevissen wrote:
>> I ran into several issues with kernel-devsrc when building Poky Sumu
>> with the meta-freescale layer for an Freescale i.mx6sx ARM board. In
>> this mail(thread) I would like to collect them all and discuss the
>> possible options to resolve them.
>
> This is probably better discussed here:
> https://lists.yoctoproject.org/listinfo/linux-yocto
>
Tnx for the pointer. However, this surprises me a bit. The charter of
that ML says: "Development list for the linux-yocto*.git Linux kernel
repositories.", while my issues are with a package contained in
openembedded-core.
> Alex
Regards,
Bas.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Summary of kernel-devsrc package issues (Sumo)
2018-06-04 9:04 Summary of kernel-devsrc package issues (Sumo) Bas Mevissen
2018-06-04 11:32 ` Alexander Kanavin
@ 2018-06-04 12:32 ` Bruce Ashfield
2018-06-04 13:35 ` Bas Mevissen
1 sibling, 1 reply; 5+ messages in thread
From: Bruce Ashfield @ 2018-06-04 12:32 UTC (permalink / raw)
To: Bas Mevissen; +Cc: Openembedded Core
[-- Attachment #1: Type: text/plain, Size: 3810 bytes --]
On Mon, Jun 4, 2018 at 5:04 AM, Bas Mevissen <abuse@basmevissen.nl> wrote:
>
>
> Hi all,
>
> I ran into several issues with kernel-devsrc when building Poky Sumu with
> the meta-freescale layer for an Freescale i.mx6sx ARM board. In this
> mail(thread) I would like to collect them all and discuss the possible
> options to resolve them.
>
> * Install dependency issues (both during image creation and manual install
> on the board):
>
> The kernel-devsrc spec file defines a number of auto-generated run-time
> dependencies. These include
> (1) /bin/awk
> (2) /usr/bin/python
>
> (1) is due to scripts/ver_linux being an awk script using /bin/awk in its
> shebang in various (vendor) kernels, even recent ones. Instead of fixing
> all those kernel sources, I would suggest:
> 1a) adding a link to /bin/awk in the awk or the kernel-devsrc package
> 1b) automatically fix the kernel source included in the kernel-devsrc
> package
> 1c) having a more helpful error message?
>
> (2) is normally fine, but on my build, there is only /usr/bin/python3. A
> manually created symlink fixed the issue. I'm wondering what a more
> permanent solution would be:
> 2a) Fix all Python script in the installed kernel source like 1b)? (the
> python3-native package does create such a symlink, but not the target one!)
> 2b) See whether there is a package that already creates that symlink and
> make kernel-devsrc depend on it?
>
> * External module build issue:
>
> When building an external module (rtl8812au driver) on the board using
> kernel-devsrc, I ran into the following issues:
>
> (3) No symlink from /lib/modules/`uname -r`/build to the kernel source.
> Solution:
> 3a) Add this symlink (and optionally "source") to kernel-devsrc,
> comparable to Fedora kernel-headers package
>
> (4) The scripts where not build, resulting in build error. Solution:
> 4b) Pre-build scripts ("make scripts") in kernel-devsrc. Should be ok, as
> the package is already arch dependent.
>
> (remarkably, there is mention of both in the kernel-devsrc.bb file, but I
> think the current solutions are wrong as the package is not ready-to-use
> currently)
>
> * Multiple kernel support:
>
> When developing, multiple kernel versions might be installed. Current
> version of the package installs in /usr/src/kernel without the kver in the
> patch.
>
> (5) So you can have only 1 set of kernel sources installed. Proposal:
> (5a) Install in /usr/src/kernels/`uname r` following the way Fedora does
> it.
>
> * Huge size of package
>
> (6) The package contains an awful lot of files and is huge. Not all of
> them are needed to compile external kernel modules
> 6a) Remove the sources and only provide what is needed to build external
> kernel modules (like fedora)
> 6b) Create the package suggested at 6a) (or add it to kernel-dev) and keep
> the devsrc as the full-source alternative.
>
>
> Your thoughts? I'm more than happy to fix the issues and provide patches.
> However, I need input on what direction to go on the issues I ran into
> until now.
>
There's already a completely re-written kernel-devsrc that I posted in the
last
dev cycle, which will be re-sent in the next few days. The only reason it
didn't
merge was due to a multlib issue, which should be sorted out now.
So please, don't do any patches on top of the existing devsrc structure,
since
it is essentially obsolete.
Cheers,
Bruce
>
> Thanks,
>
> Bas.
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
[-- Attachment #2: Type: text/html, Size: 4885 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Summary of kernel-devsrc package issues (Sumo)
2018-06-04 12:32 ` Bruce Ashfield
@ 2018-06-04 13:35 ` Bas Mevissen
0 siblings, 0 replies; 5+ messages in thread
From: Bas Mevissen @ 2018-06-04 13:35 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Openembedded Core
On 2018-06-04 14:32, Bruce Ashfield wrote:
> On Mon, Jun 4, 2018 at 5:04 AM, Bas Mevissen <abuse@basmevissen.nl>
> wrote:
>
>> Hi all,
>>
>> I ran into several issues with kernel-devsrc when building Poky Sumu
>> with the meta-freescale layer for an Freescale i.mx6sx ARM board. In
>> this mail(thread) I would like to collect them all and discuss the
>> possible options to resolve them.
>>
>> * Install dependency issues (both during image creation and manual
>> install on the board):
>>
>> The kernel-devsrc spec file defines a number of auto-generated
>> run-time dependencies. These include
>> (1) /bin/awk
>> (2) /usr/bin/python
>>
>> (1) is due to scripts/ver_linux being an awk script using /bin/awk
>> in its shebang in various (vendor) kernels, even recent ones.
>> Instead of fixing all those kernel sources, I would suggest:
>> 1a) adding a link to /bin/awk in the awk or the kernel-devsrc
>> package
>> 1b) automatically fix the kernel source included in the
>> kernel-devsrc package
>> 1c) having a more helpful error message?
>>
>> (2) is normally fine, but on my build, there is only
>> /usr/bin/python3. A manually created symlink fixed the issue. I'm
>> wondering what a more permanent solution would be:
>> 2a) Fix all Python script in the installed kernel source like 1b)?
>> (the python3-native package does create such a symlink, but not the
>> target one!)
>> 2b) See whether there is a package that already creates that symlink
>> and make kernel-devsrc depend on it?
>>
>> * External module build issue:
>>
>> When building an external module (rtl8812au driver) on the board
>> using kernel-devsrc, I ran into the following issues:
>>
>> (3) No symlink from /lib/modules/`uname -r`/build to the kernel
>> source. Solution:
>> 3a) Add this symlink (and optionally "source") to kernel-devsrc,
>> comparable to Fedora kernel-headers package
>>
>> (4) The scripts where not build, resulting in build error. Solution:
>> 4b) Pre-build scripts ("make scripts") in kernel-devsrc. Should be
>> ok, as the package is already arch dependent.
>>
>> (remarkably, there is mention of both in the kernel-devsrc.bb [1]
>> file, but I think the current solutions are wrong as the package is
>> not ready-to-use currently)
>>
>> * Multiple kernel support:
>>
>> When developing, multiple kernel versions might be installed.
>> Current version of the package installs in /usr/src/kernel without
>> the kver in the patch.
>>
>> (5) So you can have only 1 set of kernel sources installed.
>> Proposal:
>> (5a) Install in /usr/src/kernels/`uname r` following the way Fedora
>> does it.
>>
>> * Huge size of package
>>
>> (6) The package contains an awful lot of files and is huge. Not all
>> of them are needed to compile external kernel modules
>> 6a) Remove the sources and only provide what is needed to build
>> external kernel modules (like fedora)
>> 6b) Create the package suggested at 6a) (or add it to kernel-dev)
>> and keep the devsrc as the full-source alternative.
>>
>> Your thoughts? I'm more than happy to fix the issues and provide
>> patches. However, I need input on what direction to go on the issues
>> I ran into until now.
>
> There's already a completely re-written kernel-devsrc that I posted in
> the last
> dev cycle, which will be re-sent in the next few days. The only reason
> it didn't
> merge was due to a multlib issue, which should be sorted out now.
>
I wasn't aware of that. I looked up the one you posted in March and that
already addresses a lot of the issues I listed. Nice!
> So please, don't do any patches on top of the existing devsrc
> structure, since
> it is essentially obsolete.
>
Yes, definitely. I'm looking forward to see your updated version.
> Cheers,
>
> Bruce
>
>> Thanks,
>>
>> Bas.
>>
Cheers,
Bas.
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core [2]
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>
> Links:
> ------
> [1] http://kernel-devsrc.bb
> [2] http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-06-04 13:35 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-04 9:04 Summary of kernel-devsrc package issues (Sumo) Bas Mevissen
2018-06-04 11:32 ` Alexander Kanavin
2018-06-04 13:23 ` Bas Mevissen
2018-06-04 12:32 ` Bruce Ashfield
2018-06-04 13:35 ` Bas Mevissen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox