Re: [yocto] init-ifupdown: is this missing a RDEPEND to procps?
On 2013-11-20 4:15, Hans Beckérus wrote: The /etc/init.d/networking script is using sysctl to grab some parameters from /etc/sysctl.conf. This file does not exists unless procps is also installed. I can not see that init-ifupdown RDEPENDS procps. Should it not? Or is there a reason for not having it like that? No one? Should I route this question to OE-core instead? Thanks. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SRCREV how is it supposed to work?
On 2013-11-05 11:10, Robert Calhoun wrote:
-Original Message-
From: Paul Eggleton paul.eggle...@linux.intel.com
AFAIK, there are two recommended values for SRCREV assuming you are
fetching
from an SCM at all:
A) A specific revision (SHA1 hash when fetching from git)
or
B) ${AUTOREV} if you want to always build the latest version available
at
time of building. If you want to build the latest version from a branch,
specify it in branch= in the SRC_URI entry.
Anything else isn't really a good idea. Sometimes I wonder if we ought to
just
tighten this up so that only settings that make sense can be set.
The current behavior is a little non-intuitive, since using SRCREV =
${AUTOREV}
alone will not force the package to be rebuilt when SRCREV changes. Unless
I am
mistaken, $PV needs to be modified also. But modifying $PV causes its own
headaches with patching, so I've ended up using recipes based on the model
below.
Another challenge is that bitbake's fetch2 is not very well documented. I
don't
think the user and pswd fields for the svn fetcher are documented
anywhere
outside of the source code.
I'd love to help address this, but I'm not sure where I should submit
updated documentation. Is this the right place?
git://git.yoctoproject.org/yocto-docs
Hans, below is a model recipe for building current head-of-line from a
subversion repository:
A good example indeed. I will see what I can make out of it in our own recipes.
I also realized the caveats attached to finding the patch dir etc. when
auto-incrementing the version.
This will certainly help.
Thanks.
Hans
-Rob Calhoun
SST Inc
##
DESCRIPTION = example_1.0.bb, autorevving checkout example
# This says look for LICENSE in the root of the directory being checked
out. Fix
# license filename and md5sum as required.
LIC_FILES_CHKSUM = file://LICENSE;md5=abc123
# this is the rev of your recipe. Bumping it will toss the cache and redo
everything
PR = r1
# pick up latest svn rev for this module. Note this a deferred evaluation!
SRCREV = ${AUTOREV}
# ${PV} is pulled from the recipe filename, e.g. helloworld_2.7.bb -
${PV} expands to 2.7.
# We use immediate evaluation to define a new var PVBASE holding the
original value of ${PV}.
PVBASE := ${PV}
# We need to tell bitbake about our current directory structure or we
won't be able to find patches after we mess with ${PV}
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}-${PVBASE}:
# Then redefine PV to tack the svn rev onto the base version. This is
evaluated at fetch time.
# Then the package will get rebuilt any time the relevant part of the
source tree changes.
PV = ${PVBASE}.${SRCPV}
# Now we format the source code URI.
# There is nothing special about module; it is just the final directory
of the svn checkout.
# SRC_URI below is equivalent to the svn command:
# svn checkout --username=poky --password=xyzzy
https://svn.example.com/repo/trunk/example;
#
SRC_URI=
svn://svn.example.com/repo/trunk;module=example;protocol=https;user=poky;p
swd=xyzzy
# build will fail without this; it specifies where in the workdir to find
the source. The
# name must be the same as the module name in SRC_URI.
S = ${WORKDIR}/example
# BELOW NOT PART OF RECIPE; IT SHOWS WHAT THE WORK DIR LOOKS LIKE WITH
THIS RECIPE.
# By setting PV, the cache is invalidated and new code checked out each
time the
# relevant part oF the svn repo gets updated because I've made the svn
revision look
# like a package version number to bitbake.
#
# Here is a directory listing of the work dir:
#
#
poky@build:/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/example$
ls -l
#drwxrwxr-x 12 poky poky 4096 Oct 30 10:17 1.0.57400-r1
#drwxrwxr-x 12 poky poky 4096 Oct 30 11:52 1.0.57401-r1
#drwxrwxr-x 12 poky poky 4096 Oct 31 12:37 1.0.57408-r1
#drwxrwxr-x 12 poky poky 4096 Nov 1 07:56 1.0.57412-r1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem finding -lgcc when using SDK toolchain
On 2013-10-01 7:35, Khem Raj wrote:
On Oct 1, 2013, at 6:16 AM, Hans Beckérus hans.becke...@gmail.com wrote:
Hello. We have stumbled into a problem when using ld directly instead
of going through the gcc frontend.
A simple operation like this fails:
${CC} -c hello_world.c
${LD} hello_world.o -lgcc
arm-poky-linux-gnueabi-ld: cannot find -lgcc
And yes, I know -lgcc is not required in this case to compile this
one, but this is only a simple reproducer.
The real issue was discovered when trying to build U-Boot from the SDK.
To resolve this problem we are forced to provide
-Lsysroot/usr/lib/arm-poky-linux-gnueabi/4.7.2 to LDFLAGS.
But that should not be needed, should it? Anyone else bumped into this
problem? Are there any real solutions.
I am starting to think it has to do with the hardcoded installation
path in the binaries maybe?
I doubt that infact we try hard to keep it relocatable. The problem is you
are interpreting
--sysroot option to do more than what its supposed to do. when linking it
only affects INPUT, GROUP
and SEARCH_DIR linker script variables and if you look at the linker script
path to libgcc is not
specified in SEARCH_DIR, thats where gcc driver comes handy in figuring out
where the right libgcc is installed
and sometimes when you have complex multilib environments thats very handy.
linker does not know
anything about libgcc its just another library for it.
Hi Khem, thanks for your time. I am sure I put too much value into --sysroot,
but what still strikes me a bit odd is why the simple reproducer I showed
before works just fine using the local host gcc and ld? It seems to have no
issues in finding libgcc.a?
So what you are saying is that it is actually expected that U-Boot build will
fail when compiled through the SDK toolchain directly without adding additional
options to the linker? Is that also what the u-boot recipe is doing? After all,
it works fine to bitbake u-boot.
however you could do something like
${CC} -print-libgcc-file-name or ${CC} -print-file-name=libgcc.a
to get to the library
and specify that in your linker cmdline
Ok, guess it will simply give me the same path as we are currently hardcoding,
but if the toolchain moves your solution is definitely to prefer.
Thanks for the tip. Did only not know about the --print-sysroot command until
now.
-Khem
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Question about DEPENDS and eg. DEPENDS_class-native
On 2013-09-26 2:41, Hans Beckérus wrote: Hi. Browsing through the existing recipes really did not answer this since I have no clue what was the initial intent. So my quick question is if a .inc file has a DEPENDS = foo and a recipe that includes it has DEPENDS_class-native = fee, will the resulting depend be merged from the two or will DEPENDS_class-native completely override DEPENDS? If it overrides, is the correct way to merge them to do DEPENDS_append_class-native = fee? Ok, this one I managed to figure out by doing some trial and error. What I have learned from that exercise is that if you wish to extend DEPENDS specifically you need to do DEPENDS_append_class-native = pkg Doing DEPENDS_class-native = pkg will override DEPENDS completely for native builds. Please correct me if I am wrong. Thanks. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems building util-linux when wide character support is disabled in distro
On 2013-09-17 5:09, Hans Beckérus wrote:
Hi. We are having som problems building our rootfs now that our custom
distro (based on poky-tiny) no longer includes wide character support
in libc.
Here is an example of the errors we get:
| arm-poky-linux-gnueabi-libtool: link: arm-poky-linux-gnueabi-gcc
-march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mtune=cortex-a9
--sysroot=/home/qhanbec/poky/build/tmp/sysroots/zynq-zc706 -std=gnu99
-fsigned-char -fno-common -Wall -Werror=sequence-point -Wextra
-Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes
-Wno-missing-field-initializers -Wredundant-decls -Wsign-compare
-Wtype-limits -Wuninitialized -Wunused-but-set-parameter
-Wunused-but-set-variable -Wunused-parameter -Wunused-result
-Wunused-variable -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -o ul text-utils/ul.o -ltinfo
| text-utils/rev.o: In function `main':
|
/home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:139:
undefined reference to `fgetws'
|
/home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:151:
undefined reference to `fgetws'
|
/home//poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:154:
undefined reference to `wcslen'
|
/home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:160:
undefined reference to `putwchar'
|
/home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:162:
undefined reference to `putwchar'
| collect2: error: ld returned 1 exit status
The problem is that util-linux still thinks we have wide character
support (from configure.ac):
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
#include wchar.h
#include wctype.h
#include stdio.h
]], [[
wchar_t wc;
wint_t w;
w = fgetwc(stdin);
if (w == WEOF) exit(1);
wc = w;
fputwc(wc,stdout);
]])],
[AC_DEFINE(HAVE_WIDECHAR,1,Do we have wide character support?)
])
Since no linking is performed due to x-compilation, all that this does
is basically checking if wchar.h exists or not.
Actually, I think what is missing here is a AC_TRY_LINK.
But it does not seem to matter much. There are also numerous of places in the
util-linux code that are
completely missing out on checks if wide character support is available or not.
The way forward as I can see right now is to revert and put back the wide
character support in libc.
Unless I can figure out why util-linux is actually being built in the first
place? What can cause dependencies to this
package? It is not part of our IMAGE_FEATURES directly, nor indirectly and is
not installed in our rootfs.
But something requires it. Any hints on how to trace this back?
And that is also were the problem is. Even if we have disabled wide
character support in eglibc, the wchar.h header files is still copied
to our sysroot!?
Is that really how it should be when DISTRO_FEATURES_LIBC does not
include 'libc-posix-clang-wchar libc-posix-wchar-io'?
Here is our DISTRO_FEATURES (as reported by bitbake -e) and build environment:
DISTRO_FEATURES=ipv4 usbhost usbgadget ${DISTRO_FEATURES_WIFI}
libc-libm libc-crypt libc-utmp libc-getlogin libc-posix-regexp
libc-inet libc-nis sysvinit largefile nfs
Build Configuration:
BB_VERSION= 1.19.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = SUSE-LINUX-11
TARGET_SYS= arm-poky-linux-gnueabi
MACHINE = zynq-zc706
DISTRO= poky-chris
DISTRO_VERSION= 1.4+snapshot-20130917
TUNE_FEATURES = armv7a vfp cortexa9
TARGET_FPU= vfp
meta
meta-yocto
meta-yocto-bsp= master:3b38c898a4647c6a639d0dbd416b0bbacbf278f5
meta-oe = master:7c292ce28756824b1fa377d516aedd979fa41f19
Any ideas how what might be wrong here?
Thanks.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] confusion about DEPENDS vs RDEPENDS
On 2013-08-28 6:06, Paul Eggleton wrote:
Hi Hans,
On Wednesday 28 August 2013 17:08:41 Hans Beckérus wrote:
Hi, I am a little bit confused about how to handle these two and what
they are supposed to solve. I have so far never used RDEPENDS but only
DEPENDS.
DEPENDS means a build-time dependency i.e. between recipes, RDEPENDS means a
runtime dependency i.e. between packages. It is worth noting though that an
explicitly stated RDEPENDS will cause bitbake to actually build the recipe
providing the package named in the RDEPENDS value, just at a different time. To
explain exactly what each of these do:
* DEPENDS = b in recipe a will translate to a's do_configure task depending
on recipe b's do_populate_sysroot task, so that anything recipe b puts into
the sysroot is available for when a configures itself.
* RDEPENDS_${PN} = b in recipe a will translate to a's do_build task
depending on recipe b's do_package_write task, so that the package file b is
available when the output for a has been completely built (of course assuming
that recipe b produces a package called b, which it will with the default
value of PACKAGES). More importantly it will also ensure that package a is
marked as depending on b in a manner understood by the package manager being
used e.g. rpm / opkg / dpkg.
Thanks a lot! This was definitely more than I got from the description
of DEPENDS and RDEPENDS in the manual.
But I probably just read the wrong one ;)
But I am also having severe problems when building a rootfs image when
one of my user space libraries are changed from eg. libfoo.so.1 to
libfoo.so.3. Even though all my packages that have dependencies to it
includes it in a DEPENDS.
The error I get during rootfs build is:
| Computing transaction...error: Can't install
someapp-1.0-r0@cortexa9_vfp: no package provides libfoo.so.1
But there is no libfoo.so.1 in my sysroot, it has been replaced by
libfoo.so.3. I know for sure that 'someapp' was rebuilt, but still I got
the error message. What do seem to help is to force a fetch of 'someapp'
and then rebuild which sort of indicates that some garbage was left behind.
But having a package listed in DEPENDS will not force a new fetch if I am
not mistaken.
By default, if recipe foo changes and it is mentioned in the someapp
recipe's DEPENDS, then someapp's do_configure and all tasks that depend upon it
will be re-executed next time it is called for i.e. you explicitly build
someapp or build an image that contains it or some other recipe that depends
upon it. The fact that you are getting the behaviour described suggests that
this is either not happening, or more likely it is not having the desired
effect; e.g. if internally someapp's build system doesn't drop or invalidate
all of its build output when it is reconfigured then you will get this kind of
behaviour. Setting up B (the directory in which a recipe's source code is
built) separate to S (the directory in which the recipe's source code has been
unpacked to) can help with this since if they are separate, our build system
will know it can delete B before re-executing do_compile after do_configure and
you'll never have stale build output. Being able to set this up however is
highly dependent on the software being built by the individual recipe; some
lend themselves to this and others don't.
Well, I have been struggling before with packages not properly
supporting different build and source folders so I can definitely relate
to what you are saying. But, does that mean I actually *have* to do it
this way for build dependencies to work correctly? In my case we are
talking two simple autotools enabled packages and I (naively?) assumed
this was not something I had to take care of myself. What strikes me is
that you say if recipe foo changes, which is actually not the case
here! What is changed is the actual source code only. Is that what is
going wrong here? If I change my foo recipe version, would that be
different than to simply fetch/unpack the foo package source code? Is
someapp going to become purged differently in such a scenario?
Have I been using the DEPENDS variable incorrectly? Would it make a
difference if I used RDEPENDS instead?
RDEPENDS would not be appropriate in this situation, since we're talking about
a build-time dependency.
Hope that helps.
What is still somewhat unclear to me is the difference between DEPENDS
and RDEPENDS in a simple case as this.
A simple application needing a dynamic library is obviously a subject
for DEPENDS but to me that also sounds like a typical RDEPENDS?
However, when I build an image and include 'someapp', will 'libfoo.so.x'
automatically be installed or is that what I need to tell it to do using
RDEPENDS?
Cheers,
Paul
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yet another LIC_FILES_CHKSUM question
On 2013-06-12 7:55, Flanagan, Elizabeth wrote:
On Wed, Jun 12, 2013 at 6:05 AM, Hans Beckérus hans.becke...@gmail.com wrote:
In what way does LIC_FILES_CHKSUM correlate to what is specified in LICENSE?
LIC_FILES_CHKSUM *must* be specified unless LICENSE is set to CLOSED.
But, what if the package does not itself provide a license type file?
Is it then ok to simply leave LIC_FILES_CHKSUM = ?
That's kind of a tricky situation. I'm not a lawyer, but I haven't
actually seen an actual instance where there was a stated open source
license that wasn't also in the source. If there is then the correct
path is to probably put actual license text in the upstream as I can
imagine all sorts of legal issues with this. Any lawyers care to field
this on?
-b
Hi Elizabeth, I understand you are not a lawyer ;) I did not really
expect one either.
Let's tweak the question into something slightly different. Assume that
LICENSE is saying eg. GPLv2, but the COPYING file provided by the
package says GPLv3? Iow, there is a mismatch between the what the recipe
says and what the package tells you.
I am a little bit confused to how LICENSE and LIC_FILES_CHKSUM really
works together? Why do we need two different ways of telling what
license we use or actually expect? Or is LICENSE checked against the
files pointed to by LIC_FILES_CHKSUM? Should it not always be the
file(s) stored in the upstream package that dictates what license should
be applied?
Hans
Also, I could see that there was an Erlang Public License file
available in poky. But the file is named ErlPL-1.1 and there were no
maps attached to it, this patch will add that.
Hans
diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 3cb143c..ffed997 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -101,9 +101,14 @@ SPDXLICENSEMAP[AFL-1] = AFL-1.2
SPDXLICENSEMAP[AFLv2] = AFL-2.0
SPDXLICENSEMAP[AFLv1] = AFL-1.2
+#Erlang variations
+SPDXLICENSEMAP[ErlPLv1.1] = ErlPL-1.1
+SPDXLICENSEMAP[ErlPL1.1] = ErlPL-1.1
+
#Other variations
SPDXLICENSEMAP[EPLv1.0] = EPL-1.0
+
# Additional license directories. Add your custom licenses
directories this path.
# LICENSE_PATH += ${COREBASE}/custom-licenses
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] remove /usr/share/terminfo
On 2013-03-24 11:06, Jochen Trumpf wrote:
Hi Hans,
I am not subscribed to [yocto], just browsing it occasionally, so please
excuse the private email.
For this sort of thing I am using the following in my image recipe (stolen
from some gumstix image recipe in meta-gumstix-extras, danny branch):
-- cut --
# this section removes remnants of legacy sysvinit support
# for packages installed above
IMAGE_FILE_BLACKLIST += \
/etc/init.d/crond \
/etc/init.d/dbus-1 \
/etc/init.d/sshd \
remove_blacklist_files() {
for i in ${IMAGE_FILE_BLACKLIST}; do
rm -rf ${IMAGE_ROOTFS}$i
done
}
ROOTFS_POSTPROCESS_COMMAND =+ remove_blacklist_files ;
-- cut --
You can add arbitrary commands to ROOTFS_POSTPROCESS_COMMAND, e.g. your link
to the network share. As you can see, you can use wildcards in the blacklist
entries, or anything that rm -rf will understand.
In case you want to use a similar mechanism to ADD files that are not already
present on your build machine, that is not (easily) possible since
image.bbclass does not support do_fetch, so SRC_URI does not work within an
image recipe. The philosophy seems to be that you need a separate recipe to
add things.
Hope this helps.
Cheers,
Jochen
P.S.: Feel free to forward this to the list if you think it might be
interesting for other people.
Hi Jochen. Thanks for the information. As you might have seen already, I
solved it by using a .bbappend for ncurses, but I must admit that your
solution is a lot more elegant. I will try your approach instead and
keep it in mind when needing something similar in the future.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FUSE user-space library
On 2013-03-10 1:56, Philip Balister wrote: On 03/09/2013 03:45 PM, Hans Beckerus wrote: Hi. Anyone started to look at including the FUSE user-space library as part of Yocto? There are some fuse related recipes in meta-oe. Philip Ok, I will take a look. Is the meta-oe 100% compatible with a Yocto reference system? Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FUSE user-space library
On 2013-03-10 9:12, Khem Raj wrote: On Mar 10, 2013, at 6:05 AM, Hans Beckerus hans.becke...@gmail.com wrote: On 2013-03-10 1:56, Philip Balister wrote: On 03/09/2013 03:45 PM, Hans Beckerus wrote: Hi. Anyone started to look at including the FUSE user-space library as part of Yocto? There are some fuse related recipes in meta-oe. Philip Ok, I will take a look. Is the meta-oe 100% compatible with a Yocto reference system? it s a well maintained layer over oe-core and yocto uses oe-core too so I don't see much problem with it being compatible. Time to time metadata changes in oe-core affect this layer like any other layers but as long they are resolved thats normal. Thanks for the info. I found the FUSE user-space library as part of oe-meta, together with eg. sshfs. I see no issues using that also in my poky based build. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] FUSE user-space library
Hi. Anyone started to look at including the FUSE user-space library as part of Yocto? Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I control what kernel modules are being loaded?
On 2013-03-08 7:12, Eric Bénard wrote:
Hi Hans,
Le Fri, 8 Mar 2013 13:08:21 +0100,
Hans Beckérus hans.becke...@gmail.com a écrit :
Hi. I have built some custom kernel modules (.ko) using a .bb that
inherits from the module.bbclass. There is one main kernel module and
the rest are dependent on the first. Building and installing the
modules to the rootfs works fine. Next question is how do I control
what actual modules are loaded at boot, or actually how do I control
this through Yocto? To my surprise one of the kernel module loaded
automatically!? How could this happen? I did not have an entry for it
in /etc/modules. And what do I need to do to actually add entries to
/etc/modules? Or is there some other mechanism that I should use. I
tried going through the module.bbclass but must admit I lost it
somewhere in the middle ;) Any guidance would be appreciated.
when the module is built by the kernel recipe you can use :
module_autoload and you can see somme usage examples here :
http://cgit.openembedded.org/meta-handheld/tree/conf/machine/palmtx.conf
http://cgit.openembedded.org/meta-handheld/tree/conf/machine/include/palm.inc
maybe you could get inspiration from kernel.bbclass to do the same
thing in your recipe.
Eric
Thanks guys for your quick feedback. I can see that using
module_autoload_${PN} seems like a good approach, if a package maps 1:1
to a module.
In my case that is not so. The package/recipe builds six (or even more)
.ko files using one makefile.
I guess one option could be to split each module build in its own
recipe, but that is not supported by the makefile and thus would require
patching from my side in the source tree. I think the only option I have
left is to try to use /etc/modules and add the modules there in a
do_install_append().
But the problem then is, what happens if some other package also add a
/etc/modules.conf to the image folder? Will it be merged or only copied?
In the latter case last package wins which would not work out very well :(
Out of curiosity, what will module_autoload do? Will it add the .ko to
/etc/modules or does it implement some other mechanism to make a module
load automatically at boot?
I do not think that the mandatory module that is loaded originates from
udev. This is a network CM driver that basically hooks into the Linux
network stack. I do not think that udev will ever make this driver load
automatically. But I can not say for sure of course.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I control what kernel modules are being loaded?
On 2013-03-08 7:12, Eric Bénard wrote: Hi Hans, Le Fri, 8 Mar 2013 13:08:21 +0100, Hans Beckérus hans.becke...@gmail.com a écrit : Hi. I have built some custom kernel modules (.ko) using a .bb that inherits from the module.bbclass. There is one main kernel module and the rest are dependent on the first. Building and installing the modules to the rootfs works fine. Next question is how do I control what actual modules are loaded at boot, or actually how do I control this through Yocto? To my surprise one of the kernel module loaded automatically!? How could this happen? I did not have an entry for it in /etc/modules. And what do I need to do to actually add entries to /etc/modules? Or is there some other mechanism that I should use. I tried going through the module.bbclass but must admit I lost it somewhere in the middle ;) Any guidance would be appreciated. when the module is built by the kernel recipe you can use : module_autoload and you can see somme usage examples here : http://cgit.openembedded.org/meta-handheld/tree/conf/machine/palmtx.conf http://cgit.openembedded.org/meta-handheld/tree/conf/machine/include/palm.inc maybe you could get inspiration from kernel.bbclass to do the same thing in your recipe. Eric Coming to think about it, module_autoload should actually specify module, not package right? That would work then. But is this only supported in a machine.conf? Can it not be used also in e.g. the image.bb or a distro.conf? The reason is that I do not have a machine.conf in my highest layer! My layer is a simple distro that does not have any real knowledge of what hardware it is running on. My local.conf points out the actual MACHINE. The kernel modules are not hardware dependent either since they are pure network extensions so it would be wrong to have them in the machine.conf. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with applying a patch using default -pnum
On 2013-03-07 8:11, Jerrod Peach wrote:
Hans,
Are you sure you're seeing the patch system use $WORKDIR instead of $S
as the root for patching? I've had to do a lot of patching in our own
layers recently and I've always seen $S used as the root for the
patch. Are you explicitly setting S = ${WORKDIR}/git? That's what
we do for our git recipes. That's how you get the system to recognize
the source somewhere other than just $WORKDIR.
As for specifying a different -pnum, you absolutely can do that like so:
/SRC_URI += file://my-change.patch*;striplevel=X*/
X is the pnum that you want. Its default value is 1.
You may also find this page useful -- it contains all sorts of hints
for setting up your recipes in a Yocto-standard way:
https://wiki.yoctoproject.org/wiki/Recipe__Patch_Style_Guide
That's where I learned about striplevel and the preference for it over
the deprecated pnum parameter.
Kind regards,
Jerrod
Hi Jarod. Thanks, the pointer you gave will most certainly be of great
aid. I will try the striplevel approach
instead of writing my own do_patch() override.
Regarding how certain I am that the root folder is ${WORKDIR} when
patching, not at all ;)
In my do_patch() function is simply did `pwd` and it was not set to ${S}
as I set it to.
That does not mean that the built-in patch system is using ${WORKDIR}, I
am aware of that.
Things here is, even though my patch is placed in ${W} and I set ${S} to
eg. ${W}/git/some/folder,
why would it not work? In another package I set ${S} to ${WORKDIR}/git
and it works
just fine. I can not understand why setting ${S} to something else
breaks the logic?
It's not that bitbake can not find the patch file, it definitely does
that, but the -pnum seems to get
messed up. But maybe that is the whole point of having the striplevel=X
in the first place.
Hans
On Thu, Mar 7, 2013 at 7:33 AM, Hans Beckérus hans.becke...@gmail.com
mailto:hans.becke...@gmail.com wrote:
On Thu, Mar 7, 2013 at 1:12 PM, Hans Beckérus
hans.becke...@gmail.com mailto:hans.becke...@gmail.com wrote:
Hi. More problems ;)
I have a patch file that needs to be applied to a source tree
and the
patch file is copied properly to the ${WORKDIR} directory.
So far so good. But, the problem with this source tree is that it is
not built from the traditional root folder of the repo.
This means I need to change ${S} to point somewhere else. This also
causes the patch system to fail!
I did an override of do_patch() in my .bb and that seems to
work, but
I do not like to use overrides unless I really have to.
So basically, is there some way to tell the built-in patch system to
use a different -pnum value?
If there is, I could stick with the do_patch() as provided by
default.
Hans
Hmm, ok a correction from my side. Forget parts of what I said ;)
The patch system does not seem to use the value of ${S}, it is using
${WORKDIR} as the root for patching, this is also where the patch file
is placed. The problem in my case does not seem to be that is built
from a non-standard path. The reason why it fails seems to be because
the actual source is not in ${WORKDIR}, it is in ${WORKDIR}/git. The
patch file does include git as part of the source path for obvious
reasons. What am I doing wrong? Having actual source code in
${WORKDIR}/git I assume is very common for git based downloads.
Hans
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with applying a patch using default -pnum
On 2013-03-07 10:01, Jerrod Peach wrote:
On Thu, Mar 7, 2013 at 2:43 PM, Hans Beckerus hans.becke...@gmail.com
mailto:hans.becke...@gmail.com wrote:
On 2013-03-07 8:11, Jerrod Peach wrote:
Hans,
Are you sure you're seeing the patch system use $WORKDIR instead
of $S as the root for patching? I've had to do a lot of patching
in our own layers recently and I've always seen $S used as the
root for the patch. Are you explicitly setting S =
${WORKDIR}/git? That's what we do for our git recipes. That's
how you get the system to recognize the source somewhere other
than just $WORKDIR.
As for specifying a different -pnum, you absolutely can do that
like so:
/SRC_URI += file://my-change.patch*;striplevel=X*/
X is the pnum that you want. Its default value is 1.
You may also find this page useful -- it contains all sorts of
hints for setting up your recipes in a Yocto-standard way:
https://wiki.yoctoproject.org/wiki/Recipe__Patch_Style_Guide
That's where I learned about striplevel and the preference for it
over the deprecated pnum parameter.
Kind regards,
Jerrod
Hi Jarod. Thanks, the pointer you gave will most certainly be of
great aid. I will try the striplevel approach
instead of writing my own do_patch() override.
Regarding how certain I am that the root folder is ${WORKDIR} when
patching, not at all ;)
In my do_patch() function is simply did `pwd` and it was not set
to ${S} as I set it to.
That does not mean that the built-in patch system is using
${WORKDIR}, I am aware of that.
Things here is, even though my patch is placed in ${W} and I set
${S} to eg. ${W}/git/some/folder,
why would it not work? In another package I set ${S} to
${WORKDIR}/git and it works
just fine. I can not understand why setting ${S} to something else
breaks the logic?
It's not that bitbake can not find the patch file, it definitely
does that, but the -pnum seems to get
messed up. But maybe that is the whole point of having the
striplevel=X in the first place.
Hans
pnum/striplevel's purpose is to strip off the leading paths from a
patch file. If you're having trouble understanding how that works,
this link might help:
http://drupal.org/patch/apply#comment-239397
Changing $S to a different depth and having do_patch() fail is
certainly expected behavior if you don't change the value of
striplevel. Does that answer your question?
Yes, I am fully aware of how -pnum works. My confusion was based on how
bitbake will assume a certain depth and use that as default.
Actually it could have been more clever by doing a comparison between $W
(or patch file location), the patch itself, and $S.
Anyway, you did answer my question. Thanks. I will try the striplevel
tomorrow when I am back at work.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
