[yocto] nscd: missing configuration and initscript
Hello folks, currently I'm trying to add nscd to my image. This works quite fine using IMAGE_INSTALL += "nscd". The problem is that the nscd package lacks a configuration and a initscript. I've searched through the recipes and the web but I can't find any hints on it. Is there a way to add a "complete nscd" installation (with config & initscript) without writing my own recipe? What is the preferred way for this? Am I overlooking something? thanks & regards, richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fetcher failure for git repository using tag name in SRCREV
Hi folks,
I've ran into a problem using tag names in SRCREV for git repositories after
migrating from 1.4 to 1.6.1 "daisy".
Before (1.4) the following worked fine:
SRCREV = "v${PV}"
SRC_URI = "git://github.com/rleitner/psplash.git;protocol=https"
When using 1.6.1 the following error message is produced:
ERROR: Function failed: Fetcher failure for URL:
'git://github.com/rleitner/psplash.git;protocol=https'. The command git
ls-remote https://github.com/rleitner/psplash.git refs/heads/v2014-02-03
refs/tags/v2014-02-03^{} gave empty output unexpectedly
I think the refs/heads argument in the git ls-remote call should contain the
branch instead of the tag name.
A "fixed" call would then look like this:
git ls-remote https://github.com/rleitner/psplash.git refs/heads/master
refs/tags/v2014-02-03^{}
I also think I've found the error in the source and will send a patch in reply
to this message.
regards,
richard
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] bitbake: fetch/git: fix head refs in git ls-remote call
Use the branch in refs/head instead of the tag.
This allows a given tag name to differ from the branch name.
Signed-off-by: Richard Leitner
---
bitbake/lib/bb/fetch2/git.py |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index 9ca2442..d30f109 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -339,7 +339,7 @@ class Git(FetchMethod):
"""
Compute the HEAD revision for the url
"""
-search = "refs/heads/%s refs/tags/%s^{}" % (ud.unresolvedrev[name],
ud.unresolvedrev[name])
+search = "refs/heads/%s refs/tags/%s^{}" % (ud.branches[name],
ud.unresolvedrev[name])
output = self._lsremote(ud, d, search)
return output.split()[0]
--
1.7.10.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to install .deb file in Yocto on Intel Galileo
Hi,
do you want to install the .deb package during the bitbake build or in the
running system?
During the bitbake build you can use something like the following in your image
recipe.
install_my_deb() {
${STAGING_BINDIR_NATIVE}/dpkg --root=${IMAGE_ROOTFS}/
--admindir=${IMAGE_ROOTFS}/var/lib/dpkg/ -i /path/to/package.deb
}
ROOTFS_POSTPROCESS_COMMAND += "install_my_deb; "
If you like to install it in the running system make sure dpkg is installed
(try "dpkg --version").
If not: check PACKAGE_CLASSES variable. (Is package_deb set?)
hope this helps.
regards,
richard l.
On Mon, 14 Jul 2014 15:55:18 +0800
TonyZhao wrote:
> I want to install .deb file in Yocto. It's based on Intel Galileo, started
> from SD card.
> I tried dpkg -i , but it said no such command.
> Do I miss something or use the wrong command?
> Thanks.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] missing udev permissions.rules in daisy
Hi folks, I've currently ran into following problem when updating my image from 1.4 to 1.6.1: Most files under /dev (especially tty's and USB devices) have invalid permissions (crw--- 1 root root 4, 65 Jan 1 1970 /dev/ttyS1). I figured out that the /etc/udev/rules.d/permissions.rules is missing. In my image udev & udev-extraconf is in the IMAGE_INSTALL. Is there something else I have to add to let udev set group & mode again? Thank you! regards, richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Force recipe to provide specific file
Hello folks, is there a possibility to force a recipe to provide a specific file? My problem is that my own recipe is providing a file which is already provided by another recipe. I don't want to change that other recipe and the rootfs should include both package but only the specified file from my package. The following message is produced by bitbake: WARNING: The recipe ghostscript is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /opt/yocto/poky/build_2.2/tmp/sysroots/board/usr/lib/cups/filter/gstopxl Matched in manifest-board-cups-filters.populate_sysroot /opt/yocto/poky/build_2.2/tmp/sysroots/board/usr/lib/cups/filter/gstoraster Matched in manifest-board-cups-filters.populate_sysroot Please verify which package should provide the above files. The only solution which came to my mind is to remove the file from the original recipe using a bbappend, but I think this isn't a really "clean" way. Does anybody have another/better idea how to solve this "problem"? Thanks! regards, richard P.S.: I hope I'm on the correct mailing list, if not please drop me a line! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Force recipe to provide specific file
Hi,
thanks for your answer!
On Tue, 12 Aug 2014 08:27:46 -0400
"Robert P. J. Day" wrote:
> On Tue, 12 Aug 2014, Richard Leitner wrote:
>
> >
> > WARNING: The recipe ghostscript is trying to install files into a shared
> > area
> > when those files already exist. Those files and their manifest location are:
> >/opt/yocto/poky/build_2.2/tmp/sysroots/board/usr/lib/cups/filter/gstopxl
> >Matched in manifest-board-cups-filters.populate_sysroot
> >
> > /opt/yocto/poky/build_2.2/tmp/sysroots/board/usr/lib/cups/filter/gstoraster
> >Matched in manifest-board-cups-filters.populate_sysroot
> > Please verify which package should provide the above files.
> >
> > The only solution which came to my mind is to remove the file from the
> > original
> > recipe using a bbappend, but I think this isn't a really "clean" way.
> >
> > Does anybody have another/better idea how to solve this "problem"?
>
> why not just provide a .bbappend file and an overriding file?
Do you mean that I should integrate my version of the files into the
ghostscript package?
This is what I want to avoid because all cups-filters should reside in the
cups-filters package.
I've also tried the following in my ghostscript bbappend, but it does not
work. Shouldn't [1] work this way?
FILES_${PN}-cups_remove = "${exec_prefix}/lib/cups/filter/gstopxl"
FILES_${PN}-cups_remove = "${exec_prefix}/lib/cups/filter/gstoraster"
thanks & regards,
richard
[1]
https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#removing-override-style-syntax
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Force recipe to provide specific file
Hi,
On Tue, 12 Aug 2014 15:04:46 +0200
Nicolas Dechesne wrote:
> On Tue, Aug 12, 2014 at 2:58 PM, Richard Leitner
> wrote:
> >
> > I've also tried the following in my ghostscript bbappend, but it does not
> > work. Shouldn't [1] work this way?
> >
> > FILES_${PN}-cups_remove = "${exec_prefix}/lib/cups/filter/gstopxl"
> > FILES_${PN}-cups_remove = "${exec_prefix}/lib/cups/filter/gstoraster"
>
> the packaging step is using regexp to get the file list to include in
> the package. so it's unlikely that this pattern will be in FILES. it
> might be worth printing the value of FILES with bitbake -e..
I've copied the file paths from the ghostscript recipe, so they should match.
They occur in FILES when i run bitbake -e ghostscript:
FILES_ghostscript-cups=" /usr/lib/cups/filter/gstoraster
/usr/lib/cups/filter/gstopxl /usr/share/cups /etc/cups"
For some strange reasons it works when I substitute the variable and use:
FILES_${PN}-cups_remove = "/usr/lib/cups/filter/gstoraster"
FILES_${PN}-cups_remove = "/usr/lib/cups/filter/gstopxl"
Can anyone explain why? :-)
>
> but anyways, a simpler way to so the same thing would be do have a
> do_install_append() function and remove the files from ${D}. that
> would in turns have the same effect as what you are trying to do here
> i believe.
Yeah, this works, this is the way I'm currently doing it as I already mentioned
earlier.
But is this really a clean way?
What happens for example if do_install_append is already defined in the recipe?
thanks & regards,
richard
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Force recipe to provide specific file
On Fri, 22 Aug 2014 11:07:41 +0200 Anders Darander wrote: > > > What happens for example if do_install_append is already defined in the > > recipe? > > > No issue at all. The do_install_append's will just be appended one after > each other. Thanks you for this info! Maybe it would be a good idea to add it to the documentation somewhere ;-) regards, richard signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building own kernel instead of taking from git
Hi, On Mon, 8 Sep 2014 09:51:28 +0530 jags gediya wrote: > I want to build my kernel source code in yocto. For that i have > modified the required linux-imx.inc file. > > Inside that i have given kernel source directory in SRC_URI and S variable. > > Is this approach fine, or is there any better solution i can get? I think all you need to know is available in the kernel-dev manual: https://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html Generally I would prefer to copy and modify the linux-yocto custom recipe (linux-yocto-custom.bb) like described in the manual. Furthermore creating & working in your own layer would be a good idea. regards, richard signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] multiple, different kernel images in one rootfs
Hi, I'm currently using Jethro and like to include multiple, different kernel (fit)images (with different source branches/versions) in one RootFS. When booting such a system the bootloader (U-Boot) will decide which kernel to load. I've already done some searches on the Internet, but found only Bug 6945, which seems to be something similar. But I'm unable to find any documentation on it, and the commits linked to the bugzilla [1] aren't very helpful. Furthermore a similar question on the mailing list in 2015 [2] wasn't answered. So does anybody of you know how to implement that or where/how I might get started? Thanks & regards, Richard L [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=6945 [2] https://lists.yoctoproject.org/pipermail/yocto/2015-May/025031.html -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] multiple, different kernel images in one rootfs
On 03/28/2017 08:17 PM, Khem Raj wrote: > On 3/28/17 2:53 AM, Richard Leitner wrote: >> Hi, >> I'm currently using Jethro and like to include multiple, different >> kernel (fit)images (with different source branches/versions) in one >> RootFS. When booting such a system the bootloader (U-Boot) will decide >> which kernel to load. >> > > There is/was a way to build multiple kernels see something like this > > https://git.digitalstrom.org/dss-oe/dss-oe/commit > /1e0c2307a910e8fc7e2482a757c52277c4f4e01e > > might help you Thank you for your response. So it seems they copied and renamed the kernel classes from poky.git and let the second kernel image use the newly added class? Am I understanding this correctly? Is this the "preferred" way? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-java][PATCH 3/3] openjdk-8: use ca-certificates-java
Hi,
this commit of yours breaks the build on meta-java's current
mater-next branch (when building an image containing openjre-8
or openjdk-8) with following message:
ERROR: openjre-8-test-image-1.0-r0 do_rootfs: [log_check] openjre-8-test-image:
found 1 error message in the logfile:
[log_check] E:
/yocto/meta-java-test/build/tmp/work/qemuarm-poky-linux-gnueabi/openjre-8-test-image/1.0-r0/rootfs/etc/ca-certificates/update.d/ca-certificates-java-hook
exited with code 1.
ERROR: openjre-8-test-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/yocto/meta-java-test/build/tmp/work/qemuarm-poky-linux-gnueabi/openjre-8-test-image/1.0-r0/temp/log.do_rootfs.19892
ERROR: Task
(/yocto/meta-java-test/meta-java/recipes-images/images/openjre-8-test-image.bb:do_rootfs)
failed with exit code '1'
The logfile contains following error:
Running hooks in
/yocto/meta-java-test/build/tmp/work/qemuarm-poky-linux-gnueabi/openjre-8-test-image/1.0-r0/rootfs/etc/ca-certificates/update.d...
/yocto/meta-java-test/build/tmp/work/qemuarm-poky-linux-gnueabi/openjre-8-test-image/1.0-r0/rootfs/etc/ca-certificates/update.d/ca-certificates-java-hook:
no JVM_LIBDIR specified
E:
/yocto/meta-java-test/build/tmp/work/qemuarm-poky-linux-gnueabi/openjre-8-test-image/1.0-r0/rootfs/etc/ca-certificates/update.d/ca-certificates-java-hook
exited with code 1.
done.
Therefore it will be removed from master-next.
It would be great if you could send an fixed version.
Thank you!
regards;Richard.L
On 03/30/2018 10:40 AM, André Draszik wrote:
> From: André Draszik
>
> The OpenJDK-8 package currently comes with a trustStore
> that was generated at OpenJDK-8-native build time from
> *all* certificates available in the system, not just from
> those that are marked as trusted.
>
> This isn't right...
>
> openjdk-8 and openjre-8 now RDEPENDS on (and use) the CA
> certificates as provided by the ca-certificates-java
> package just added.
>
> This makes sure that Java now uses the same trusted CA
> certificates as the rest of the system.
>
> Signed-off-by: André Draszik
> ---
> recipes-core/openjdk/openjdk-8-common.inc | 2 ++
> recipes-core/openjdk/openjdk-8-cross.inc | 12 +++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/recipes-core/openjdk/openjdk-8-common.inc
> b/recipes-core/openjdk/openjdk-8-common.inc
> index b2020c3..c8d157e 100644
> --- a/recipes-core/openjdk/openjdk-8-common.inc
> +++ b/recipes-core/openjdk/openjdk-8-common.inc
> @@ -254,3 +254,5 @@ def version_specific_cflags(d):
> CFLAGS_append = " ${@version_specific_cflags(d)}"
> CXXFLAGS_append = " ${@version_specific_cflags(d)}"
> CXX_append = " -std=gnu++98"
> +
> +RDEPENDS_${PN} = "ca-certificates-java"
> diff --git a/recipes-core/openjdk/openjdk-8-cross.inc
> b/recipes-core/openjdk/openjdk-8-cross.inc
> index d70c946..6795c92 100644
> --- a/recipes-core/openjdk/openjdk-8-cross.inc
> +++ b/recipes-core/openjdk/openjdk-8-cross.inc
> @@ -57,7 +57,6 @@ EXTRA_OECONF_append = "\
> --with-sys-root=${STAGING_DIR_HOST} \
> --with-tools-dir=${STAGING_DIR_NATIVE} \
> --with-boot-jdk=${STAGING_LIBDIR_NATIVE}/jvm/openjdk-8-native \
> -
> --with-cacerts-file=${STAGING_LIBDIR_NATIVE}/jvm/openjdk-8-native/jre/lib/security/cacerts
> \
> \
> --disable-precompiled-headers \
> --disable-zip-debug-info \
> @@ -88,6 +87,17 @@ do_install_append() {
>pack200 --repack --effort=9 --segment-limit=-1
> --modification-time=latest --strip-debug "$0"'
>fi
> fi
> +
> +if [ -d ${D}${JDK_HOME} ] ; then
> + rm ${D}${JDK_HOME}/jre/lib/security/cacerts
> + ln -s ${@os.path.relpath("${sysconfdir}/ssl/certs/java/cacerts",
> "${JDK_HOME}/jre/lib/security/cacerts")} \
> +${D}${JDK_HOME}/jre/lib/security/cacerts
> +fi
> +if [ -d ${D}${JRE_HOME} ] ; then
> + rm ${D}${JRE_HOME}/lib/security/cacerts
> + ln -s ${@os.path.relpath("${sysconfdir}/ssl/certs/java/cacerts",
> "${JRE_HOME}/lib/security/cacerts")} \
> +${D}${JRE_HOME}/lib/security/cacerts
> +fi
> }
>
> export MAKE_VERBOSE = "y"
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH 1/3] AUTHORS: add list of git commit authors
Added an initial AUTHORS list in alphabetical order, created with following commandline: git log --format='%aN <%aE>' | sort -u Signed-off-by: Richard Leitner --- AUTHORS | 13 + 1 file changed, 13 insertions(+) diff --git a/AUTHORS b/AUTHORS index e69de29..953d867 100644 --- a/AUTHORS +++ b/AUTHORS @@ -0,0 +1,13 @@ +List of contributors (in alphabetical order): + +Aws Ismail +Juro Bystricky +Khem Raj +Matthew Allum +Olaf Mandel +Richard Purdie +Rob Bradford +Robert Bragg +Ross Burton +Samuel Ortiz +Tomas Frydrych -- 2.1.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH 3/3] README: add "Contributing" guideline
The "Contributing" guideline section should help people sending their patches correctly. A similar section is available in nearly all layers/repositories hosted on yoctoproject.org. Therefore add it also the the psplash repository. Signed-off-by: Richard Leitner --- README | 18 ++ 1 file changed, 18 insertions(+) diff --git a/README b/README index 86ef6ba..8779a38 100644 --- a/README +++ b/README @@ -8,3 +8,21 @@ rotation. Its visual look is configurable by basic source changes. Also included is a 'client' command utility for sending information to psplash such as boot progress information. + +Contributing + +To contribute to this layer you should submit the patches for review to the +mailing list (yocto@yoctoproject.org). + +Please refer to +http://openembedded.org/wiki/Commit_Patch_Message_Guidelines +for some useful guidelines to be followed when submitting patches. + +Mailing list: +https://lists.yoctoproject.org/listinfo/yocto + +When creating patches, please use something like: +git format-patch -M -s --subject-prefix='psplash][PATCH' origin + +When sending patches, please use something like: +git send-email --to yocto@yoctoproject.org -- 2.1.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH 2/3] add initial .gitignore
This initial version of .gitignore contains all files created during a build. Signed-off-by: Richard Leitner --- .gitignore | 20 1 file changed, 20 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..7cf14ed --- /dev/null +++ b/.gitignore @@ -0,0 +1,20 @@ +configure +config.h +config.h.in +config.log +config.status +config.guess +config.sub +depcomp +Makefile +Makefile.in +install-sh +missing +aclocal.m4 +autom4te.cache/ +.deps/ +*.o + +psplash +psplash-write +stamp-h1 -- 2.1.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [psplash][PATCH 3/3] README: add "Contributing" guideline
Hi Philip, On 04/13/2016 09:42 PM, Philip Balister wrote: >> + >> > +Contributing >> > + >> > +To contribute to this layer you should submit the patches for review to >> > the >> > +mailing list (yocto@yoctoproject.org). >> > + >> > +Please refer to >> > +http://openembedded.org/wiki/Commit_Patch_Message_Guidelines >> > +for some useful guidelines to be followed when submitting patches. >> > + >> > +Mailing list: >> > +https://lists.yoctoproject.org/listinfo/yocto >> > + >> > +When creating patches, please use something like: >> > +git format-patch -M -s --subject-prefix='psplash][PATCH' origin >> > + >> > +When sending patches, please use something like: >> > +git send-email --to yocto@yoctoproject.org >> > > I cut and paste this line from the meta-oe README for sending patches, > it is a bit simpler than the two step process: > > https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/README#L9 The line we are talking about is: git send-email -M -1 --to openembedded-de...@lists.openembedded.org --subject-prefix=meta-oe][PATCH isn't it? You're right, for one patch this line is simpler/faster. But basically I like to create the patches first (and be able to review them) and send them afterwards in a separate step. Nonetheless if you like to add the "direct" send-email line I would at least suggest to: a) use "origin" as rev instead of "-1" b) add "--annotate" regards, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH 2/5] psplash-fb: fix sign-compare warning
Cast font->index[i] to wchar_t for the comparison.
This fixes following sign-compare warning:
psplash-fb.c: In function 'psplash_font_glyph':
psplash-fb.c:452:33: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
Signed-off-by: Richard Leitner
---
psplash-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/psplash-fb.c b/psplash-fb.c
index 38cd6a4..cdcbc19 100644
--- a/psplash-fb.c
+++ b/psplash-fb.c
@@ -449,7 +449,7 @@ psplash_font_glyph (const PSplashFont *font, wchar_t wc,
u_int32_t **bitmap)
{
for (i = font->offset[wc & mask]; font->index[i]; i += 2)
{
- if ((font->index[i] & ~mask) == (wc & ~mask))
+ if ((wchar_t)(font->index[i] & ~mask) == (wc & ~mask))
{
if (bitmap != NULL)
*bitmap = &font->content[font->index[i+1]];
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH 0/5] fix -Wextra GCC warnings
This series adds the -Wextra GCC flag and fixes the found warnings. Richard Leitner (5): configure: add -Wextra GCC flag psplash-fb: fix sign-compare warning psplash-fb: remove unused parameter from psplash_fb_text_size psplash: remove unused parameter length from parse_command psplash: fix remaining unused-parameter warnings configure.ac | 2 +- psplash-console.c | 2 +- psplash-fb.c | 5 ++--- psplash-fb.h | 3 +-- psplash.c | 10 +- psplash.h | 6 ++ 6 files changed, 16 insertions(+), 12 deletions(-) -- 2.1.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH 1/5] configure: add -Wextra GCC flag
Enable extra warnings when using GCC. Signed-off-by: Richard Leitner --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index bf00e91..1c4d919 100644 --- a/configure.ac +++ b/configure.ac @@ -9,7 +9,7 @@ AC_PROG_CC AC_STDC_HEADERS if test "x$GCC" = "xyes"; then -GCC_FLAGS="-g -Wall" +GCC_FLAGS="-g -Wall -Wextra" fi AC_SUBST(GCC_FLAGS) -- 2.1.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH 5/5] psplash: fix remaining unused-parameter warnings
Define UNUSED macro for GCC's ((__unused__)) attribute and use it for
the remaining unused-parameter warnings. These unused parameters are
required due to the definition of the sighandler_t.
This fixes following unused-parameter warnings:
psplash.c: In function 'psplash_exit':
psplash.c:36:19: warning: unused parameter 'signum' [-Wunused-parameter]
psplash-console.c: In function 'vt_request':
psplash-console.c:27:17: warning: unused parameter 'sig'
[-Wunused-parameter]
Signed-off-by: Richard Leitner
---
psplash-console.c | 2 +-
psplash.c | 2 +-
psplash.h | 6 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/psplash-console.c b/psplash-console.c
index 9b7dfb9..055f5b0 100644
--- a/psplash-console.c
+++ b/psplash-console.c
@@ -24,7 +24,7 @@ static int VTNumInitial = -1;
static int Visible= 1;
static void
-vt_request (int sig)
+vt_request (int UNUSED(sig))
{
DBG("mark, visible:%i", Visible);
diff --git a/psplash.c b/psplash.c
index c72d120..04d3d49 100644
--- a/psplash.c
+++ b/psplash.c
@@ -33,7 +33,7 @@
)
void
-psplash_exit (int signum)
+psplash_exit (int UNUSED(signum))
{
DBG("mark");
diff --git a/psplash.h b/psplash.h
index 22d73a3..7b1298f 100644
--- a/psplash.h
+++ b/psplash.h
@@ -69,6 +69,12 @@ typedef intbool;
#define DBG(x, a...) do {} while (0)
#endif
+#ifdef __GNUC__
+# define UNUSED(x) UNUSED_ ## x __attribute__((__unused__))
+#else
+# define UNUSED(x) UNUSED_ ## x
+#endif
+
typedef struct PSplashFont
{
char *name;/* Font name. */
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH 3/5] psplash-fb: remove unused parameter from psplash_fb_text_size
This fixes following unused-parameter warning:
psplash-fb.c: In function 'psplash_fb_text_size':
psplash-fb.c:464:43: warning: unused parameter 'fb' [-Wunused-parameter]
Signed-off-by: Richard Leitner
---
psplash-fb.c | 3 +--
psplash-fb.h | 3 +--
psplash.c| 2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/psplash-fb.c b/psplash-fb.c
index cdcbc19..8daaf6f 100644
--- a/psplash-fb.c
+++ b/psplash-fb.c
@@ -461,8 +461,7 @@ psplash_font_glyph (const PSplashFont *font, wchar_t wc,
u_int32_t **bitmap)
}
void
-psplash_fb_text_size (PSplashFB *fb,
- int*width,
+psplash_fb_text_size (int*width,
int*height,
const PSplashFont *font,
const char *text)
diff --git a/psplash-fb.h b/psplash-fb.h
index c6c3144..a4a0f4c 100644
--- a/psplash-fb.h
+++ b/psplash-fb.h
@@ -78,8 +78,7 @@ psplash_fb_draw_image (PSplashFB*fb,
uint8 *rle_data);
void
-psplash_fb_text_size (PSplashFB *fb,
- int*width,
+psplash_fb_text_size (int*width,
int*height,
const PSplashFont *font,
const char *text);
diff --git a/psplash.c b/psplash.c
index 185f38e..65cf514 100644
--- a/psplash.c
+++ b/psplash.c
@@ -45,7 +45,7 @@ psplash_draw_msg (PSplashFB *fb, const char *msg)
{
int w, h;
- psplash_fb_text_size (fb, &w, &h, &radeon_font, msg);
+ psplash_fb_text_size (&w, &h, &radeon_font, msg);
DBG("displaying '%s' %ix%i\n", msg, w, h);
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH 4/5] psplash: remove unused parameter length from parse_command
This fixes following unused-parameter warning:
psplash.c: In function 'parse_command':
psplash.c:105:49: warning: unused parameter 'length'
[-Wunused-parameter]
Signed-off-by: Richard Leitner
---
psplash.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/psplash.c b/psplash.c
index 65cf514..c72d120 100644
--- a/psplash.c
+++ b/psplash.c
@@ -102,7 +102,7 @@ psplash_draw_progress (PSplashFB *fb, int value)
}
static int
-parse_command (PSplashFB *fb, char *string, int length)
+parse_command (PSplashFB *fb, char *string)
{
char *command;
@@ -175,14 +175,14 @@ psplash_main (PSplashFB *fb, int pipe_fd, int timeout)
if (command[length-1] == '\0')
{
- if (parse_command(fb, command, strlen(command)))
+ if (parse_command(fb, command))
return;
length = 0;
}
else if (command[length-1] == '\n')
{
command[length-1] = '\0';
- if (parse_command(fb, command, strlen(command)))
+ if (parse_command(fb, command))
return;
length = 0;
}
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH] psplash: add option to read startup message from file
This patch adds an option to read the displayed message from a file.
Additionally the maximum length for the read string can be defined.
If both, a message (STARTUP_MSG) and a file (STARTUP_MSG_FILE) are
defined the content of the file will be appended to the message.
The string will be cutted after the given maximum number of chars.
For these changes the following defines were introduced:
PSPLASH_STARTUP_MSG_MAX_LEN ... maximum lenght of the complete message
PSPLASH_STARTUP_MSG_FILE .. path to the file to read
Signed-off-by: Richard Leitner
---
psplash-config.h | 5 +
psplash.c| 29 -
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/psplash-config.h b/psplash-config.h
index 82bb76d..7fa44fa 100644
--- a/psplash-config.h
+++ b/psplash-config.h
@@ -21,6 +21,11 @@
/* Text to output on program start; if undefined, output nothing */
#define PSPLASH_STARTUP_MSG ""
+#define PSPLASH_STARTUP_MSG_MAX_LEN 32
+
+/* File to read and display its first line on program start;
+ * if undefined, output nothing; if MSG is defined also, append to it */
+#define PSPLASH_STARTUP_MSG_FILE ""
/* Bool indicating if the image is fullscreen, as opposed to split screen */
#define PSPLASH_IMG_FULLSCREEN 0
diff --git a/psplash.c b/psplash.c
index 04d3d49..b7d2d28 100644
--- a/psplash.c
+++ b/psplash.c
@@ -208,6 +208,9 @@ main (int argc, char** argv)
intpipe_fd, i = 0, angle = 0, ret = 0;
PSplashFB *fb;
bool disable_console_switch = FALSE;
+ char msg[PSPLASH_STARTUP_MSG_MAX_LEN];
+ intmsglen;
+ FILE *fd_msg;
signal(SIGHUP, psplash_exit);
signal(SIGINT, psplash_exit);
@@ -298,9 +301,33 @@ main (int argc, char** argv)
psplash_draw_progress (fb, 0);
+ memset(msg, 0, PSPLASH_STARTUP_MSG_MAX_LEN);
+ msglen = 0;
#ifdef PSPLASH_STARTUP_MSG
- psplash_draw_msg (fb, PSPLASH_STARTUP_MSG);
+ snprintf(msg, PSPLASH_STARTUP_MSG_MAX_LEN, "%s", PSPLASH_STARTUP_MSG);
+ msglen = strlen(msg);
#endif
+#ifdef PSPLASH_STARTUP_MSG_FILE
+ fd_msg = fopen (PSPLASH_STARTUP_MSG_FILE, "r");
+ if (fd_msg)
+{
+ if (msglen == 0)
+{
+ fgets (msg, PSPLASH_STARTUP_MSG_MAX_LEN, fd_msg);
+}
+ else
+{
+ fgets (&msg[msglen + 1], PSPLASH_STARTUP_MSG_MAX_LEN - msglen - 1,
fd_msg);
+ msg[msglen] = ' ';
+}
+ fclose (fd_msg);
+}
+ msglen = strlen(msg);
+#endif
+
+ /* draw message if we have one */
+ if (msglen > 0)
+psplash_draw_msg (fb, msg);
psplash_main (fb, pipe_fd, 0);
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [psplash][PATCH] psplash: add option to read startup message from file
Hi, are any comments or possible improvements? On 04/15/2016 10:49 AM, Richard Leitner wrote: > This patch adds an option to read the displayed message from a file. > Additionally the maximum length for the read string can be defined. > If both, a message (STARTUP_MSG) and a file (STARTUP_MSG_FILE) are > defined the content of the file will be appended to the message. > The string will be cutted after the given maximum number of chars. > > For these changes the following defines were introduced: > PSPLASH_STARTUP_MSG_MAX_LEN ... maximum lenght of the complete message > PSPLASH_STARTUP_MSG_FILE .. path to the file to read regards, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [psplash][PATCH] Add fbdev option to set the proper /dev/fbX.
Hi Julien,
comments on the code are below.
On 05/22/2016 07:46 PM, Julien Gueytat wrote:
> It works exactly the same way than the angle parameter:
> * --angle <-> /etc/rotation file
> * --fbdev <-> /etc/fbdev file
>
> Signed-off-by: Julien Gueytat
> ---
> psplash-fb.c | 16 ++--
> psplash-fb.h | 4 ++--
> psplash.c| 57 -
> 3 files changed, 44 insertions(+), 33 deletions(-)
>
> diff --git a/psplash-fb.c b/psplash-fb.c
> index 8daaf6f..d344e5a 100644
> --- a/psplash-fb.c
> +++ b/psplash-fb.c
> @@ -99,18 +99,20 @@ attempt_to_change_pixel_format (PSplashFB *fb,
> }
>
> PSplashFB*
> -psplash_fb_new (int angle)
> +psplash_fb_new (int angle, int fbdev_id)
> {
>struct fb_var_screeninfo fb_var;
>struct fb_fix_screeninfo fb_fix;
>int off;
> - char*fbdev;
> + char fbdev[9] = "/dev/fb0";
>
>PSplashFB *fb = NULL;
>
> - fbdev = getenv("FBDEV");
> - if (fbdev == NULL)
> -fbdev = "/dev/fb0";
> + if (fbdev_id > 0 && fbdev_id < 10)
> +{
> +// Conversion from integer to ascii.
> +fbdev[7] = fbdev_id + 48;
> +}
You removed the possiblity to get the fb device from FBDEV!
Please don't to that as people may rely on that feature!
If you like to add a fbdev commandline option make sure it can co-exist
with the already available methods for setting this option.
And don't forget to add documentation!
>
>if ((fb = malloc (sizeof(PSplashFB))) == NULL)
> {
...
> @@ -205,35 +205,41 @@ int
> main (int argc, char** argv)
> {
>char *tmpdir;
> - intpipe_fd, i = 0, angle = 0, ret = 0;
> + intpipe_fd, i = 0, angle = 0, fbdev_id = 0, ret = 0;
>PSplashFB *fb;
>bool disable_console_switch = FALSE;
> -
> +
>signal(SIGHUP, psplash_exit);
>signal(SIGINT, psplash_exit);
>signal(SIGQUIT, psplash_exit);
>
> - while (++i < argc)
> -{
> - if (!strcmp(argv[i],"-n") || !strcmp(argv[i],"--no-console-switch"))
> -{
> - disable_console_switch = TRUE;
> - continue;
> - }
> + while (++i < argc) {
> +if (!strcmp(argv[i],"-n") || !strcmp(argv[i],"--no-console-switch"))
> + {
> +disable_console_switch = TRUE;
> +continue;
> + }
> +
> +if (!strcmp(argv[i],"-a") || !strcmp(argv[i],"--angle"))
> + {
> +if (++i >= argc) goto fail;
> +angle = atoi(argv[i]);
> +continue;
> + }
> +
> +if (!strcmp(argv[i],"-f") || !strcmp(argv[i],"--fbdev"))
> + {
> +if (++i >= argc) goto fail;
> +fbdev_id = atoi(argv[i]);
> +continue;
> + }
>
> - if (!strcmp(argv[i],"-a") || !strcmp(argv[i],"--angle"))
> -{
> - if (++i >= argc) goto fail;
> - angle = atoi(argv[i]);
> - continue;
> - }
> -
> fail:
>fprintf(stderr,
> - "Usage: %s [-n|--no-console-switch][-a|--angle
> <0|90|180|270>]\n",
> - argv[0]);
> + "Usage: %s [-n|--no-console-switch][-a|--angle
> <0|90|180|270>][-f|--fbdev <0..9>]\n",
> + argv[0]);
>exit(-1);
> -}
> + }
Please use the same coding style everywhere in psplash.
Furthermore please avoid/remove trailing whitespaces in new/changed code
>
>tmpdir = getenv("TMPDIR");
>
> @@ -245,10 +251,10 @@ main (int argc, char** argv)
>if (mkfifo(PSPLASH_FIFO, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP))
> {
>if (errno!=EEXIST)
> - {
> - perror("mkfifo");
> - exit(-1);
> - }
> + {
> + perror("mkfifo");
> + exit(-1);
> + }
> }
This change is irrelevant for new fbdev option.
Please send this whitespace fix as a separate patch.
>
>pipe_fd = open (PSPLASH_FIFO,O_RDONLY|O_NONBLOCK);
> @@ -262,10 +268,11 @@ main (int argc, char** argv)
>if (!disable_console_switch)
> psplash_console_switch ();
>
> - if ((fb = psplash_fb_new(angle)) == NULL) {
> + if ((fb = psplash_fb_new(angle,fbdev_id)) == NULL)
> +{
> ret = -1;
> goto fb_fail;
> - }
> +}
>
>/* Clear the background with #ecece1 */
>psplash_fb_draw_rect (fb, 0, 0, fb->width, fb->height,
>
IMHO in this case fixing the whitespace is fine because the if clause
needs to be adopted for the new option.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [psplash][PATCH] psplash: add option to read startup message from file
Any comments/updates on that patch of mine?
On 04/15/2016 10:49 AM, Richard Leitner wrote:
> This patch adds an option to read the displayed message from a file.
> Additionally the maximum length for the read string can be defined.
> If both, a message (STARTUP_MSG) and a file (STARTUP_MSG_FILE) are
> defined the content of the file will be appended to the message.
> The string will be cutted after the given maximum number of chars.
>
> For these changes the following defines were introduced:
> PSPLASH_STARTUP_MSG_MAX_LEN ... maximum lenght of the complete message
> PSPLASH_STARTUP_MSG_FILE .. path to the file to read
>
> Signed-off-by: Richard Leitner
> ---
> psplash-config.h | 5 +
> psplash.c| 29 -
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/psplash-config.h b/psplash-config.h
> index 82bb76d..7fa44fa 100644
> --- a/psplash-config.h
> +++ b/psplash-config.h
> @@ -21,6 +21,11 @@
>
> /* Text to output on program start; if undefined, output nothing */
> #define PSPLASH_STARTUP_MSG ""
> +#define PSPLASH_STARTUP_MSG_MAX_LEN 32
> +
> +/* File to read and display its first line on program start;
> + * if undefined, output nothing; if MSG is defined also, append to it */
> +#define PSPLASH_STARTUP_MSG_FILE ""
>
> /* Bool indicating if the image is fullscreen, as opposed to split screen */
> #define PSPLASH_IMG_FULLSCREEN 0
> diff --git a/psplash.c b/psplash.c
> index 04d3d49..b7d2d28 100644
> --- a/psplash.c
> +++ b/psplash.c
> @@ -208,6 +208,9 @@ main (int argc, char** argv)
>intpipe_fd, i = 0, angle = 0, ret = 0;
>PSplashFB *fb;
>bool disable_console_switch = FALSE;
> + char msg[PSPLASH_STARTUP_MSG_MAX_LEN];
> + intmsglen;
> + FILE *fd_msg;
>
>signal(SIGHUP, psplash_exit);
>signal(SIGINT, psplash_exit);
> @@ -298,9 +301,33 @@ main (int argc, char** argv)
>
>psplash_draw_progress (fb, 0);
>
> + memset(msg, 0, PSPLASH_STARTUP_MSG_MAX_LEN);
> + msglen = 0;
> #ifdef PSPLASH_STARTUP_MSG
> - psplash_draw_msg (fb, PSPLASH_STARTUP_MSG);
> + snprintf(msg, PSPLASH_STARTUP_MSG_MAX_LEN, "%s", PSPLASH_STARTUP_MSG);
> + msglen = strlen(msg);
> #endif
> +#ifdef PSPLASH_STARTUP_MSG_FILE
> + fd_msg = fopen (PSPLASH_STARTUP_MSG_FILE, "r");
> + if (fd_msg)
> +{
> + if (msglen == 0)
> +{
> + fgets (msg, PSPLASH_STARTUP_MSG_MAX_LEN, fd_msg);
> +}
> + else
> +{
> + fgets (&msg[msglen + 1], PSPLASH_STARTUP_MSG_MAX_LEN - msglen - 1,
> fd_msg);
> + msg[msglen] = ' ';
> +}
> + fclose (fd_msg);
> +}
> + msglen = strlen(msg);
> +#endif
> +
> + /* draw message if we have one */
> + if (msglen > 0)
> +psplash_draw_msg (fb, msg);
>
>psplash_main (fb, pipe_fd, 0);
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [psplash][PATCH] Add fbdev option to set the proper /dev/fbX.
Hi Julien, On 05/30/2016 11:55 PM, Julien Gueytat wrote: > > For FBDEV, I have been told on #yocto that the FBENV variable is kind of > useless at least for the startup as the environment is not read yet. > This why I replaced it. But I will let it available in the next patch if > this is what should be done. Ok, sorry I didn't knew that. In that case you can of course remove that "feature". But please add this description somewhere to the commit text or create a separate patch for it. So that everybody can understand why it was removed (also in the future). > > For the psplash documentation, I did not find any. Where am I supposed > to complete it? I just took a second look at your patch and saw that you've added the option to the "Usage text". This should be enough. Sorry that I didn't see it the first time! :-( Unfortunately there is no "real" documentation for psplash AFAIK... > > Thanks for pointing out that a patch should serve a single purpose. I > will correct the indentation in a separate commit. > Thanks. Furthermore please add yourself to the AUTHORS file and add a short description to the ChangeLog when re-sending the patch(es). Thank you! kind regards, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system
Hi, you can adjust the mount behaviour for example in your udev mount script (if you use udev). If you have a fixed name/mountpoint for your media you can pre-create that folder (for example /media/data-logging) and let udev's mount.sh mount media which matches your criteria to that path. kind regards, richard On 06/13/2016 11:22 PM, Jeffrey D Boyer wrote: > Hello, > > > > New to the list here, so I’m sorry if this question has been asked > before, but I couldn’t find a direct answer to it. > > > > I have a yocto image that was built using the following bb script line: > IMAGE_FEATURES += " read-only-rootfs". > > > > As this image eventually resides on a static flash device, it must be > read-only. However, the system hardware supports removable media (SD > card and USB drives), and I’d like to be able to mount and write to > those removable drives / partitions for data logging purposes. What > needs to be done in order to make the /media directory auto-mountable > when a “read-only” image is specified by the build script? > > > > Thanks. > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [psplash][PATCH] psplash: add option to read startup message from file
Any comments/news on that patch from APRIL? On 04/15/2016 10:49 AM, Richard Leitner wrote: > This patch adds an option to read the displayed message from a file. > Additionally the maximum length for the read string can be defined. > If both, a message (STARTUP_MSG) and a file (STARTUP_MSG_FILE) are > defined the content of the file will be appended to the message. > The string will be cutted after the given maximum number of chars. > > For these changes the following defines were introduced: > PSPLASH_STARTUP_MSG_MAX_LEN ... maximum lenght of the complete message > PSPLASH_STARTUP_MSG_FILE .. path to the file to read > > Signed-off-by: Richard Leitner -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] suggestions for version controlling multi-layer reproducible builds?
Hi, On 12/12/2016 05:03 PM, Bryan Evenson wrote: > > For my setup I have a separate package that is the distribution > version number. Whenever we release an update, the distribution > version number is updated. We then tag all our layers with the > distribution version number for proper record keeping. The Angstrom > distribution was (or maybe still is?) doing something similar and was > the inspiration for our setup. > > ... > > > Any time we release an update, no matter how minor, we update the > distribution version package. Otherwise, as you state, you could > have an update that you can't reproduce. We also archive the package > repository and generated image files for each release so we can flash > a board with a previous release and test from there. It can be a > pain to get the process down the first time, but after that a simple > Bash script can take care of all the hard work for you and ensure you > don't skip a step. > I'm using a similar approach, but instead of using a separate "version package" I'm using the "BUILDNAME" and "DISTRO_VERSION" variables in my distro.conf. Then depending on how "large" the release is and which changes it includes the Major, Minor or Patchlevel of the version is increased. Furthermore (like Bryan already mentioned) for every release a tag in every layer containing the DISTRO_VERSION is created. The layer setup/checkout and build then is automated by a shellscript. This shellscript takes the version as an argument and produces the images, source archives, update packages and everything else needed for a (nearly) reproducible builds. Hope that helps. regards, Richard L -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] help with meta-java
Hi, unfortunately, due to a different focus on my day job in the previous months I didn't had time for doing any work on meta-java. This will change in the coming weeks and I will start to review and test patches again. Nonetheless it would be great if one of the other listed maintainers (or somebody else) can support me as there will be significant refactoring, cleanup and update work to be done ;-) regards;Richard.L On 05/11/2019 09:18, Vincent Prince wrote: Hi Tim, There are some pending stuff on meta-java ML openembedded-de...@lists.openembedded.org and layer is not zeus compatible yet. I'm trying to contact layer maintainers for several weeks, i don't know if information is obsolete or if people are too busy/away? Main layer maintainers: Henning Heinold Maxin John Otavio Salvador Richard Leitner For now, I just use master-next, and I'm considering using https://github.com/AdoptOpenJDK/ prebuilds, meta-java is quite hard to understand I found :) Best regards, Vincent Le lun. 4 nov. 2019 à 18:23, Shockley, Timothy a écrit : Helllo, I am looking for some help with meta-java, specifically upgrading to zeus branch and also upgrading openjdk to a more recent release in order to address CVEs. Wondering if there is anyone else working / needing this? Thanks, Tim Shockley -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Errors with update-rc.d: /etc/init.d/XXX exists during rc.d purge (use -f to force)
Hi,
I have problems with the update-rc.d class in my recipes.
When I want to update a package which inherits update-rc.d (in my case samba)
using dpkg -i I get the following error:
>root@host:~# dpkg -i /media/USBSTICK/samba-ads_3.5.22-r4_armel.deb
>(Reading database ... 11931 files and directories currently installed.)
>Preparing to replace samba-ads 3.5.22-r3 (using
>.../samba-ads_3.5.22-r4_armel.deb) ...
>Stopping Samba: smbd nmbd winbindd
>Unpacking replacement samba-ads ...
>update-rc.d: /etc/init.d/samba exists during rc.d purge (use -f to force)
>dpkg: warning: subprocess old post-removal script returned error exit status 1
>dpkg: trying script from the new package instead ...
>update-rc.d: /etc/init.d/samba exists during rc.d purge (use -f to force)
>dpkg: error processing /media/USBSTICK/samba-ads_3.5.22-r4_armel.deb
>(--install):
> subprocess new post-removal script returned error exit status 1
>update-rc.d: /etc/init.d/samba exists during rc.d purge (use -f to force)
>dpkg: error while cleaning up:
> subprocess new post-removal script returned error exit status 1
>Errors were encountered while processing:
> /media/USBSTICK/samba-ads_3.5.22-r4_armel.deb
When I afterwards want to remove/purge the package it fails with the following
message:
>root@host:~# dpkg -P samba-ads
>dpkg: error processing samba-ads (--purge):
> Package is in a very bad inconsistent state - you should
> reinstall it before attempting a removal.
>Errors were encountered while processing:
> samba-ads
The only way how to fix that problem is to manually remove the initscript and
then install the update:
>root@000C320C08C0:~# rm /etc/init.d/samba
>root@000C320C08C0:~# dpkg -i /media/USBSTICK/samba-ads_3.5.22-r4_armel.deb
>(Reading database ... 11931 files and directories currently installed.)
>Preparing to replace samba-ads 3.5.22-r3 (using
>.../samba-ads_3.5.22-r4_armel.deb) ...
>Unpacking replacement samba-ads ...
> Removing any system startup links for samba ...
> /etc/rc0.d/K20samba
> /etc/rc1.d/K20samba
> /etc/rc2.d/S20samba
> /etc/rc3.d/S20samba
> /etc/rc4.d/S20samba
> /etc/rc5.d/S20samba
> /etc/rc6.d/K20samba
>Setting up samba-ads (3.5.22-r4) ...
> Adding system startup for /etc/init.d/samba.
>Starting Samba: smbd nmbd winbindd.
The update-rc.d part of my recipe is shown below.
>inherit autotools update-rc.d
>...
>INITSCRIPT_NAME = "samba"
>INITSCRIPT_PARAMS = "defaults"
>...
>do_install_append() {
> ...
> install -D -m 755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/samba
> ...
>}
Does anybody have an idea how to fix that issue? Would be really great!
Thank you!
Regards,
Richard
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH] Add option to read message from file
Add an option to read the displayed message from a file.
Additionally the maximum length for the read string can be defined.
The string will then be cut after the given number of chars.
It is also possible to define a prefix which is displayed in front
of the read file content.
If no file is defined a hardcoded message (using MSG like before)
can be displayed.
For these changes the following defines were introduced:
MSG_FILE_PATH .. path to the file
MSG_FILE_MAX_LEN ... number of chars read from file
MSG_FILE_PREFIX text displayed in front of the file content
Signed-off-by: Richard Leitner
---
psplash.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/psplash.c b/psplash.c
index 09cf0d0..093a99a 100644
--- a/psplash.c
+++ b/psplash.c
@@ -23,6 +23,20 @@
#include "psplash-bar-img.h"
#include "radeon-font.h"
+/* Here you can define a message which will be displayed above the
+ * progress bar.
+ * The message can be either read from a file:
+ *Set MSG_FILE_PATH (and if needed MSG_FILE_{MAX_LEN,PREFIX})
+ *to display the first MSG_FILE_MAX_LEN characters
+ *of the first line from MSG_FILE_PATH as message.
+ *Additionally the content of MSG_FILE_PREFIX will be displayed
+ *before the read message. */
+#define MSG_FILE_PATH ""
+#define MSG_FILE_MAX_LEN 32
+#define MSG_FILE_PREFIX ""
+/* Or a fixed string can be used:
+ *If MSG_FILE is not set or not readable
+ *the content of MSG will be used as message. */
#define MSG ""
void
@@ -204,6 +218,8 @@ main (int argc, char** argv)
intpipe_fd, i = 0, angle = 0, ret = 0;
PSplashFB *fb;
bool disable_console_switch = FALSE;
+ FILE *fd_msg;
+ char *str_msg;
signal(SIGHUP, psplash_exit);
signal(SIGINT, psplash_exit);
@@ -287,7 +303,30 @@ main (int argc, char** argv)
psplash_draw_progress (fb, 0);
- psplash_draw_msg (fb, MSG);
+ /* Draw message from file or defined MSG */
+ fd_msg = fopen (MSG_FILE_PATH, "r");
+ if (fd_msg==NULL) {
+psplash_draw_msg (fb, MSG);
+ } else {
+str_msg = (char*) malloc (
+ (MSG_FILE_MAX_LEN + strlen(MSG_FILE_PREFIX) + 1)*sizeof(char));
+if (str_msg != NULL && fgets (str_msg, MSG_FILE_MAX_LEN, fd_msg)!=NULL) {
+ if (strlen (MSG_FILE_PREFIX) > 0) {
+/* if MSG_FILE_PREFIX is set, prepend it to str_msg */
+memmove (str_msg + strlen(MSG_FILE_PREFIX) + 1, str_msg,
strlen(str_msg));
+strcpy (str_msg, MSG_FILE_PREFIX);
+ /* replace \0 after MSG_FILE_PREFIX with a space */
+str_msg[strlen(MSG_FILE_PREFIX)] = ' ';
+ }
+ psplash_draw_msg (fb, str_msg);
+ free (str_msg);
+} else {
+ /* MSG_FILE_PATH is empty (or malloc failed)
+ *so display MSG_FILE_PREFIX only */
+ psplash_draw_msg (fb, MSG_FILE_PREFIX);
+}
+fclose (fd_msg);
+ }
psplash_main (fb, pipe_fd, 0);
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [psplash][PATCH] Add option to read message from file
Hi everybody,
I recently sent a patch for psplash to add the ability to read the displayed
message from a file.
I'd appreciate any comments on it!
Thanks and best regards,
Richard Leitner
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On
> Behalf Of Richard Leitner - SKIDATA
> Sent: Tuesday, October 01, 2013 2:51 PM
> To: Yocto Project Discussion ML (yocto@yoctoproject.org)
> Subject: [yocto] [psplash][PATCH] Add option to read message from file
>
> Add an option to read the displayed message from a file.
> Additionally the maximum length for the read string can be defined.
> The string will then be cut after the given number of chars.
> It is also possible to define a prefix which is displayed in front of the
> read file content.
>
> If no file is defined a hardcoded message (using MSG like before) can be
> displayed.
>
> For these changes the following defines were introduced:
> MSG_FILE_PATH .. path to the file
> MSG_FILE_MAX_LEN ... number of chars read from file MSG_FILE_PREFIX text
> displayed in front of the file content
>
> Signed-off-by: Richard Leitner
> ---
> psplash.c | 41 -
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/psplash.c b/psplash.c
> index 09cf0d0..093a99a 100644
> --- a/psplash.c
> +++ b/psplash.c
> @@ -23,6 +23,20 @@
> #include "psplash-bar-img.h"
> #include "radeon-font.h"
>
> +/* Here you can define a message which will be displayed above the
> + * progress bar.
> + * The message can be either read from a file:
> + *Set MSG_FILE_PATH (and if needed MSG_FILE_{MAX_LEN,PREFIX})
> + *to display the first MSG_FILE_MAX_LEN characters
> + *of the first line from MSG_FILE_PATH as message.
> + *Additionally the content of MSG_FILE_PREFIX will be displayed
> + *before the read message. */
> +#define MSG_FILE_PATH ""
> +#define MSG_FILE_MAX_LEN 32
> +#define MSG_FILE_PREFIX ""
> +/* Or a fixed string can be used:
> + *If MSG_FILE is not set or not readable
> + *the content of MSG will be used as message. */
> #define MSG ""
>
> void
> @@ -204,6 +218,8 @@ main (int argc, char** argv)
>intpipe_fd, i = 0, angle = 0, ret = 0;
>PSplashFB *fb;
>bool disable_console_switch = FALSE;
> + FILE *fd_msg;
> + char *str_msg;
>
>signal(SIGHUP, psplash_exit);
>signal(SIGINT, psplash_exit);
> @@ -287,7 +303,30 @@ main (int argc, char** argv)
>
>psplash_draw_progress (fb, 0);
>
> - psplash_draw_msg (fb, MSG);
> + /* Draw message from file or defined MSG */
> + fd_msg = fopen (MSG_FILE_PATH, "r");
> + if (fd_msg==NULL) {
> +psplash_draw_msg (fb, MSG);
> + } else {
> +str_msg = (char*) malloc (
> + (MSG_FILE_MAX_LEN + strlen(MSG_FILE_PREFIX) + 1)*sizeof(char));
> +if (str_msg != NULL && fgets (str_msg, MSG_FILE_MAX_LEN, fd_msg)!=NULL) {
> + if (strlen (MSG_FILE_PREFIX) > 0) {
> +/* if MSG_FILE_PREFIX is set, prepend it to str_msg */
> +memmove (str_msg + strlen(MSG_FILE_PREFIX) + 1, str_msg,
> strlen(str_msg));
> +strcpy (str_msg, MSG_FILE_PREFIX);
> + /* replace \0 after MSG_FILE_PREFIX with a space */
> +str_msg[strlen(MSG_FILE_PREFIX)] = ' ';
> + }
> + psplash_draw_msg (fb, str_msg);
> + free (str_msg);
> +} else {
> + /* MSG_FILE_PATH is empty (or malloc failed)
> +*so display MSG_FILE_PREFIX only */
> + psplash_draw_msg (fb, MSG_FILE_PREFIX);
> +}
> +fclose (fd_msg);
> + }
>
>psplash_main (fb, pipe_fd, 0);
>
> --
> 1.7.10.4
>
> ___
> 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] [psplash][PATCH] Add option to read message from file
Hi everybody,
a few weeks ago I sent this patch for psplash to add the ability to read the
displayed message from a file.
Due to the fact there was no response I think there are no objections against
it, or was the message just ignored?
If the patch is fine I'd be happy if it gets applied :-)
Thanks and best regards,
Richard Leitner
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On
> Behalf Of Richard Leitner - SKIDATA
> Sent: Tuesday, October 01, 2013 2:51 PM
> To: Yocto Project Discussion ML (yocto@yoctoproject.org)
> Subject: [yocto] [psplash][PATCH] Add option to read message from file
>
> Add an option to read the displayed message from a file.
> Additionally the maximum length for the read string can be defined.
> The string will then be cut after the given number of chars.
> It is also possible to define a prefix which is displayed in front of the
> read file content.
>
> If no file is defined a hardcoded message (using MSG like before) can be
> displayed.
>
> For these changes the following defines were introduced:
> MSG_FILE_PATH .. path to the file
> MSG_FILE_MAX_LEN ... number of chars read from file MSG_FILE_PREFIX text
> displayed in front of the file content
>
> Signed-off-by: Richard Leitner
> ---
> psplash.c | 41 -
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/psplash.c b/psplash.c
> index 09cf0d0..093a99a 100644
> --- a/psplash.c
> +++ b/psplash.c
> @@ -23,6 +23,20 @@
> #include "psplash-bar-img.h"
> #include "radeon-font.h"
>
> +/* Here you can define a message which will be displayed above the
> + * progress bar.
> + * The message can be either read from a file:
> + *Set MSG_FILE_PATH (and if needed MSG_FILE_{MAX_LEN,PREFIX})
> + *to display the first MSG_FILE_MAX_LEN characters
> + *of the first line from MSG_FILE_PATH as message.
> + *Additionally the content of MSG_FILE_PREFIX will be displayed
> + *before the read message. */
> +#define MSG_FILE_PATH ""
> +#define MSG_FILE_MAX_LEN 32
> +#define MSG_FILE_PREFIX ""
> +/* Or a fixed string can be used:
> + *If MSG_FILE is not set or not readable
> + *the content of MSG will be used as message. */
> #define MSG ""
>
> void
> @@ -204,6 +218,8 @@ main (int argc, char** argv)
>intpipe_fd, i = 0, angle = 0, ret = 0;
>PSplashFB *fb;
>bool disable_console_switch = FALSE;
> + FILE *fd_msg;
> + char *str_msg;
>
>signal(SIGHUP, psplash_exit);
>signal(SIGINT, psplash_exit);
> @@ -287,7 +303,30 @@ main (int argc, char** argv)
>
>psplash_draw_progress (fb, 0);
>
> - psplash_draw_msg (fb, MSG);
> + /* Draw message from file or defined MSG */
> + fd_msg = fopen (MSG_FILE_PATH, "r");
> + if (fd_msg==NULL) {
> +psplash_draw_msg (fb, MSG);
> + } else {
> +str_msg = (char*) malloc (
> + (MSG_FILE_MAX_LEN + strlen(MSG_FILE_PREFIX) + 1)*sizeof(char));
> +if (str_msg != NULL && fgets (str_msg, MSG_FILE_MAX_LEN, fd_msg)!=NULL) {
> + if (strlen (MSG_FILE_PREFIX) > 0) {
> +/* if MSG_FILE_PREFIX is set, prepend it to str_msg */
> +memmove (str_msg + strlen(MSG_FILE_PREFIX) + 1, str_msg,
> strlen(str_msg));
> +strcpy (str_msg, MSG_FILE_PREFIX);
> + /* replace \0 after MSG_FILE_PREFIX with a space */
> +str_msg[strlen(MSG_FILE_PREFIX)] = ' ';
> + }
> + psplash_draw_msg (fb, str_msg);
> + free (str_msg);
> +} else {
> + /* MSG_FILE_PATH is empty (or malloc failed)
> +*so display MSG_FILE_PREFIX only */
> + psplash_draw_msg (fb, MSG_FILE_PREFIX);
> +}
> +fclose (fd_msg);
> + }
>
>psplash_main (fb, pipe_fd, 0);
>
> --
> 1.7.10.4
>
> ___
> 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] Errors with update-rc.d: /etc/init.d/XXX exists during rc.d purge (use -f to force)
Hi Paul, good to hear I'm not the only one suffering from this issue... No, I've received no response on the mailing list yet, but maybe someone has a hint for us now? The only "workaround" I found is to purge the package and afterwards install the new version. I know this is a really dirty workaround, but it's the only "solution" I found. Have you discovered any other workarounds, Paul? regards Richard >-Original Message- >From: Stath, Paul [mailto:pst...@axxcelera.com] >Sent: Wednesday, November 27, 2013 4:49 PM >To: Richard Leitner - SKIDATA >Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during rc.d purge >(use -f to force) > >Richard -- > >I am also getting the "update-rc.d: /etc/init.d/XXX exists during rc.d purge" >error when I attempt to install a newer version of one of my packages. > >It doesn't look like you received any response to your post to the yocto >mailing list. > >Did you get any response, or did you discover a workaround? > >-- >Paul Stath >Axxcelera Broadband Wireless ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Errors with update-rc.d: /etc/init.d/XXX exists during rc.d purge (use -f to force)
Hi Paul,
thank you for that hint and description of your workaround!
Looks like you've invested a little bit more time into working around this
issue than me :-)
I've added "-f" to the update-rc.d.bbclass and now it's working like a charm:
diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index d8cc342..dbb5781 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -33,7 +33,7 @@ updatercd_postrm() {
if test "$D" != ""; then
OPT="-f -r $D"
else
- OPT=""
+ OPT="-f"
fi
if type update-rc.d >/dev/null 2>/dev/null; then
update-rc.d $OPT ${INITSCRIPT_NAME} remove
Nonetheless, I think there have to be a "cleaner" way to solve this issue than
forcing the update-rc.d.
Maybe someone else has an idea how to solve this problem?
regards,
Richard
> -Original Message-
> From: Stath, Paul [mailto:pst...@axxcelera.com]
> Sent: Wednesday, November 27, 2013 5:40 PM
> To: Richard Leitner - SKIDATA
> Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during rc.d
> purge (use -f to
> force)
>
> Richard --
>
> My "workaround" was a little less drastic than yours. (grin)
>
> Before upgrading to the new package via 'dpkg -i', I would edit the postrm
> script in
> /var/lib/dpkg/info/,postrm, adding the "-f" argument to "force" the
> symlink removal, as suggested by the error message.
>
> Then the upgrade install works correctly. (With only a warning from the
> postrm script
> of the previous package.)
>
> I believe that the issue is that when installing a package over an earlier
> release, dpkg
> performs the following steps:
>
> 1) Extract control files of new package
> 2) Execute "prerm" script of previous package if applicable.
> 3) Execute "preinst" script of new package.
> 4) Unpack new files and backup old files.
> 5) Execute "postrm" script of previous package if applicable.
> 6) Configure the package
>
> When installing a newer version of the package, the "postrm" in step 5 fails,
> because
> the initscript from the new package is extracted in step 4, and update-rc.d
> w/o the "-f"
> argument exits with a non-zero return code.
>
> I would argue that the "updatercd_postrm()" stanza in the update-rc.d.bbclass
> should
> include the "-f" flag.
> (Anyone on the list want to chime in on this?)
>
> In the meantime, I have added my own "updatercd_postrm()" stanza in the
> .bbappend
> file for the package I'm having issues with, which overrides the one provided
> by
> update-rc.d.bbclass.
>
> updatercd_postrm() {
>update-rc.d $D -f ${INITSCRIPT_NAME} remove }
>
> --
> Paul Stath
> Axxcelera Broadband Wireless
>
> >From: Richard Leitner - SKIDATA [richard.leit...@skidata.com]
> >Sent: Wednesday, November 27, 2013 11:02 AM
> >To: Stath, Paul
> >Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> >Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during
> >rc.d purge (use -f to force)
> >
> >Hi Paul,
> >good to hear I'm not the only one suffering from this issue...
> >No, I've received no response on the mailing list yet, but maybe someone has
> >a hint
> for us now?
> >
> >The only "workaround" I found is to purge the package and afterwards install
> >the
> new version.
> >I know this is a really dirty workaround, but it's the only "solution" I
> >found.
> >
> >Have you discovered any other workarounds, Paul?
> >
> >regards
> >Richard
> >
> >>-Original Message-
> >>From: Stath, Paul [mailto:pst...@axxcelera.com]
> >>Sent: Wednesday, November 27, 2013 4:49 PM
> >>To: Richard Leitner - SKIDATA
> >>Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during
> >>rc.d purge (use -f to force)
> >>
> >>Richard --
> >>
> >>I am also getting the "update-rc.d: /etc/init.d/XXX exists during rc.d
> >>purge" error
> when I attempt to install a newer version of one of my packages.
> >>
> >>It doesn't look like you received any response to your post to the yocto
> >>mailing list.
> >>
> >>Did you get any response, or did you discover a workaround?
> >>
> >>--
> >>Paul Stath
> >>Axxcelera Broadband Wireless
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] SRCREV for BBLAYERS
Hi, I've a question regarding the BBLAYERS variable. Is it possible to set some kind of a SRCREV (=> git tag/branch/commit-id) for a path listed in BBLAYERS? I came to this question because I've two different branches in my meta layer: one for development and one for 'stable' releases. Therefore I have also two different build dirs and want to 'pin' the branches/tags to the build dir (preferable via the bblayers.conf). I think this should be possible because at the start of a build the revs are displayed like: meta-yocto = "[branch]:[commit-id]" The problem is that I wasn't able to find any answers or solutions on the web so I ask you now for help. I'd appreciate any kind of help! Thanks! best regards, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SRCREV for BBLAYERS
Hi Paul, thanks for your quick answer! I'll work with separate checkouts for now... But now I've got another question: Is there any possibility to submit something like a feature request for this? And is there a (realistic) chance that this feature gets implemented? If so, where should this request go? To the bitbake-devel list? best regards, Richard > -Original Message- > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > Sent: Monday, February 03, 2014 3:46 PM > To: Richard Leitner - SKIDATA > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] SRCREV for BBLAYERS > > Hi Richard, > > On Monday 03 February 2014 12:17:04 Richard Leitner - SKIDATA wrote: > > I've a question regarding the BBLAYERS variable. > > Is it possible to set some kind of a SRCREV (=> git > > tag/branch/commit-id) for a path listed in BBLAYERS? > > > > I came to this question because I've two different branches in my meta > > layer: one for development and one for 'stable' releases. Therefore I > > have also two different build dirs and want to 'pin' the branches/tags > > to the build dir (preferable via the bblayers.conf). I think this > > should be possible because at the start of a build the revs are displayed > > like: > > meta-yocto = "[branch]:[commit-id]" The problem is that I wasn't able > > to find any answers or solutions on the web so I ask you now for help. > > The build system doesn't actually manage checking out/updating layers for > you, it only > reports the revision if there is one, so this functionality isn't supported. > Probably the > easiest way to handle this would be to keep two separate checkouts. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem with own kernel recipe on Dora
Hi Yocto-Community,
as the subject already says I've a problem with my kernel recipe after the
"migration" from the Dylan to the Dora (10.0.1) branch.
I've tried the 10.0.1 release tag as well as the current dora master
(50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b).
The kernel recipe I'm using is derived from the skeleton:
DESCRIPTION = "Linux Kernel"
SECTION = "kernel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
inherit kernel
KSRC = "/home/leri/VCS/git/linux"
KBRANCH = "master"
SRC_URI =
"git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
SRCREV = "2014_03_07"
PR = "sd_15.2"
LINUX_VERSION = "${PV}"
LINUX_VERSION_EXTENSION = "-${PR}+${SRCREV}"
COMPATIBLE_MACHINE = "skidata-harmony|smartcpu"
KERNEL_IMAGETYPE = "uImage"
SRC_URI += "file://defconfig"
require recipes-kernel/linux/linux-yocto.inc
This recipe was working well with the Dylan branch and following changes:
-SRC_URI =
"git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
+SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel"
+S = "${WORKDIR}/git"
When compiled with the dora branch the kernel hangs at "Starting kernel..." and
doesn't start:
## Booting kernel from Legacy Image at ...
Image Name: Linux-3.1.10-sd_15.2
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:3181616 Bytes = 3 MiB
Load Address: 8000
Entry Point: 8000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
I've already looked through the migration notes in the manual but I'm unable to
find any hints...
Are there any ideas why the kernel doesn't start with the Dora branch?
Thank you for your help!
best regards,
Richard
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with own kernel recipe on Dora
Hi Richard,
thanks for your quick response.
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Tuesday, April 22, 2014 10:23 AM
> To: Richard Leitner - SKIDATA
> Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> Subject: Re: [yocto] Problem with own kernel recipe on Dora
>
> On Tue, 2014-04-22 at 07:52 +, Richard Leitner - SKIDATA wrote:
> > Hi Yocto-Community,
> > as the subject already says I've a problem with my kernel recipe after the
> "migration" from the Dylan to the Dora (10.0.1) branch.
> > I've tried the 10.0.1 release tag as well as the current dora master
> (50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b).
> >
> > The kernel recipe I'm using is derived from the skeleton:
> > DESCRIPTION = "Linux Kernel"
> > SECTION = "kernel"
> > LICENSE = "GPLv2"
> > LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> > inherit kernel
> > KSRC = "/home/leri/VCS/git/linux"
> > KBRANCH = "master"
> > SRC_URI =
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> > SRCREV = "2014_03_07"
> > PR = "sd_15.2"
> > LINUX_VERSION = "${PV}"
> > LINUX_VERSION_EXTENSION = "-${PR}+${SRCREV}"
> > COMPATIBLE_MACHINE = "skidata-harmony|smartcpu"
> > KERNEL_IMAGETYPE = "uImage"
> > SRC_URI += "file://defconfig"
> > require recipes-kernel/linux/linux-yocto.inc
> >
> >
> > This recipe was working well with the Dylan branch and following changes:
> > -SRC_URI =
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> > +SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel"
> > +S = "${WORKDIR}/git"
> >
> >
> > When compiled with the dora branch the kernel hangs at "Starting kernel..."
> > and
> doesn't start:
> > ## Booting kernel from Legacy Image at ...
> >Image Name: Linux-3.1.10-sd_15.2
> >Image Type: ARM Linux Kernel Image (uncompressed)
> >Data Size:3181616 Bytes = 3 MiB
> >Load Address: 8000
> >Entry Point: 8000
> >Verifying Checksum ... OK
> >Loading Kernel Image ... OK
> > OK
> >
> > Starting kernel ...
> >
> >
> > I've already looked through the migration notes in the manual but I'm
> > unable to find
> any hints...
> > Are there any ideas why the kernel doesn't start with the Dora branch?
>
> We saw an issue recently on beaglebone that looked very like this. It turned
> out the
> load address for the kernel was conflicting in memory with the device tree
> binary.
Do you mean that the bootloader was loading the device tree binary into the
load address of the kernel?
>
> It easily be something different but I thought I'd mention it.
Do you have any idea how to further debug the problem?
regards,
Richard
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with own kernel recipe on Dora
> -Original Message-
> From: Nicolas Dechesne [mailto:nicolas.deche...@linaro.org]
> Sent: Tuesday, April 22, 2014 1:35 PM
> To: Richard Leitner - SKIDATA
> Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> Subject: Re: [yocto] Problem with own kernel recipe on Dora
>
> On Tue, Apr 22, 2014 at 9:52 AM, Richard Leitner - SKIDATA
> wrote:
> > Hi Yocto-Community,
> > as the subject already says I've a problem with my kernel recipe after the
> "migration" from the Dylan to the Dora (10.0.1) branch.
> > I've tried the 10.0.1 release tag as well as the current dora master
> (50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b).
> >
> > The kernel recipe I'm using is derived from the skeleton:
> > DESCRIPTION = "Linux Kernel"
> > SECTION = "kernel"
> > LICENSE = "GPLv2"
> > LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> > inherit kernel
> > KSRC = "/home/leri/VCS/git/linux"
> > KBRANCH = "master"
> > SRC_URI =
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> > SRCREV = "2014_03_07"
> > PR = "sd_15.2"
> > LINUX_VERSION = "${PV}"
> > LINUX_VERSION_EXTENSION = "-${PR}+${SRCREV}"
> > COMPATIBLE_MACHINE = "skidata-harmony|smartcpu"
> > KERNEL_IMAGETYPE = "uImage"
> > SRC_URI += "file://defconfig"
> > require recipes-kernel/linux/linux-yocto.inc
> >
> >
> > This recipe was working well with the Dylan branch and following changes:
> > -SRC_URI =
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> > +SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel"
> > +S = "${WORKDIR}/git"
> >
> >
> > When compiled with the dora branch the kernel hangs at "Starting kernel..."
> > and
> doesn't start:
> > ## Booting kernel from Legacy Image at ...
> >Image Name: Linux-3.1.10-sd_15.2
> >Image Type: ARM Linux Kernel Image (uncompressed)
> >Data Size:3181616 Bytes = 3 MiB
> >Load Address: 8000
> >Entry Point: 8000
> >Verifying Checksum ... OK
> >Loading Kernel Image ... OK
> > OK
> >
> > Starting kernel ...
> >
> >
> > I've already looked through the migration notes in the manual but I'm
> > unable to find
> any hints...
> > Are there any ideas why the kernel doesn't start with the Dora branch?
>
> you don't mention anything about gcc, so assuming you are using the 'default'
> gcc for
> each release, dylan has 4.7, and dora has 4.8. On a couple of ARM platforms,
> i have
> seen similar issue when using gcc-4.8 with old kernel (
> the following linux kernel patches were used to fix the boot problem:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=455bd4c430b0c
> 0a361f38e8658a0d6cb469942b5
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=418df63adac56
> 841ef6b0f1fcf435bc64d4ed177
>
> They should cleanly apply to v3.1 which you seem to be using.
>
Thank you very much Nico!
These two patches fixed the problem and the kernel is booting again :-)
Just for completeness: Yes, I'm using the "default" gcc version and the two
patches applied cleanly to my 3.1 branch.
regards,
Richard
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Binary {deb,rpm} package install without repackaging
Hi everybody,
I've got a question regarding the binary deb/rpm packages in yocto.
Is there any possibility to install a binary deb/rpm package in the rootfs
build without repackaging it?
Naively I'm for example thinking of an option in the image recipe like:
ADDITIONAL_PACKAGES += "/path/to/package.{deb,rpm}"
The point is that all possible solutions I found using recipes are extracting
and then repackaging the package.
Due to the fact that during the repackaging all meta data and
{pre,post}{rm,inst} scripts of the original package are lost this is a "no-go"
for me.
I'd appreciate any help and hints!
Thanks!
best regards,
Richard
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Binary {deb,rpm} package install without repackaging
Hi,
thanks for that hint!
I finally managed to install a "third party" deb package using the
ROOTFS_POSTPROCESS_COMMAND [1] in my rootfs.bb recipe.
Although I not fully understand why the "--admindir" parameter is required when
the "--root" parameter is given.
The ROOTFS_POSTPROCESS_COMMAND I'm using is:
ROOTFS_POSTPROCESS_COMMAND += "${STAGING_BINDIR_NATIVE}/dpkg
--root=${IMAGE_ROOTFS}/ --admindir=${IMAGE_ROOTFS}/var/lib/dpkg/ -i
/path/to/package.deb"
I think pretty the same command will work for rpm packages.
Can anybody of you explain to me why "--root" AND "--admindir" are required for
dpkg to work correctly?
According to the dpkg manpage --admindir shouldn't be required when --root is
given:
--admindir=dir
Change default administrative directory, which contains
many files that give information about status of
installed or uninstalled packages, etc. (Defaults to
/var/lib/dpkg)
--root=dir
Changing root changes instdir to dir and admindir to
dir/var/lib/dpkg.
best regards,
Richard
[1]
http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-ROOTFS_POSTPROCESS_COMMAND
> From: Gaurang Shastri [mailto:gmshas...@gmail.com]
> Sent: Monday, April 28, 2014 11:45 AM
> To: Richard Leitner - SKIDATA
> Subject: Re: [yocto] Binary {deb,rpm} package install without repackaging
>
> Dear Richard,
>
> Do you want to copy some of the RPM to final ROOTFS image before ROOTFS image
> is created or you want to install some of the RPM package before ROOTFS
> image is created ??
>
> ROOTFS_POSTPROCESS_COMMAND or ROOTFS_POSTINSTALL_COMMAND is the way to go.
>
> I did however run into a problem when running my script. Using variable ${D}
> in my ROOTFS_POSTINSTALL_COMMAND gives the “wrong” path - it points to
> …/image and I’d expect it to contain the path to …/rootfs.
> It seem the variable isreplaced before my function is executed.
>
> I solved this by using variable ${IMAGE_ROOTFS} instead.
>
> //Gaurang Shastri
>
>
>
> On Mon, Apr 28, 2014 at 1:29 PM, Richard Leitner - SKIDATA
> wrote:
> > Hi everybody,
> > I've got a question regarding the binary deb/rpm packages in yocto.
> >
> > Is there any possibility to install a binary deb/rpm package in the rootfs
> > build without repackaging it?
> > Naively I'm for example thinking of an option in the image recipe like:
> > ADDITIONAL_PACKAGES += "/path/to/package.{deb,rpm}"
> >
> > The point is that all possible solutions I found using recipes are
> > extracting and then repackaging the package.
> > Due to the fact that during the repackaging all meta data and
> > {pre,post}{rm,inst} scripts of the original package are lost this is a
> > "no-go" for me.
> >
> > I'd appreciate any help and hints!
> >
> > Thanks!
> >
> > best regards,
> > Richard
--
___
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] Errors with update-rc.d: /etc/init.d/XXX exists during rc.d purge (use -f to force)
Hi everybody again,
is there any update on this?
I'm facing the same issue with the 1.5.2 release.
I don't want to add that "-f" in meta/classes/update-rc.d.bbclass if there is a
better solution. (And I'm quite sure there must be a better one ;-) )
Maybe overriding the postrm function in my own meta-layer with some kind of
bbclassappend?
regards,
Richard
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On
> Behalf Of Richard Leitner - SKIDATA
> Sent: Thursday, November 28, 2013 3:02 PM
> To: Stath, Paul
> Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> Subject: Re: [yocto] Errors with update-rc.d: /etc/init.d/XXX exists during
> rc.d purge
> (use -f to force)
>
> Hi Paul,
> thank you for that hint and description of your workaround!
> Looks like you've invested a little bit more time into working around this
> issue than me
> :-)
>
> I've added "-f" to the update-rc.d.bbclass and now it's working like a charm:
>
> diff --git a/meta/classes/update-rc.d.bbclass
> b/meta/classes/update-rc.d.bbclass
> index d8cc342..dbb5781 100644
> --- a/meta/classes/update-rc.d.bbclass
> +++ b/meta/classes/update-rc.d.bbclass
> @@ -33,7 +33,7 @@ updatercd_postrm() {
> if test "$D" != ""; then
> OPT="-f -r $D"
> else
> - OPT=""
> + OPT="-f"
> fi
> if type update-rc.d >/dev/null 2>/dev/null; then
> update-rc.d $OPT ${INITSCRIPT_NAME} remove
>
>
> Nonetheless, I think there have to be a "cleaner" way to solve this issue
> than forcing
> the update-rc.d.
> Maybe someone else has an idea how to solve this problem?
>
> regards,
> Richard
>
>
> > -Original Message-
> > From: Stath, Paul [mailto:pst...@axxcelera.com]
> > Sent: Wednesday, November 27, 2013 5:40 PM
> > To: Richard Leitner - SKIDATA
> > Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> > Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during
> > rc.d purge (use -f to
> > force)
> >
> > Richard --
> >
> > My "workaround" was a little less drastic than yours. (grin)
> >
> > Before upgrading to the new package via 'dpkg -i', I would edit the
> > postrm script in /var/lib/dpkg/info/,postrm, adding the "-f"
> > argument to "force" the symlink removal, as suggested by the error message.
> >
> > Then the upgrade install works correctly. (With only a warning from
> > the postrm script of the previous package.)
> >
> > I believe that the issue is that when installing a package over an
> > earlier release, dpkg performs the following steps:
> >
> > 1) Extract control files of new package
> > 2) Execute "prerm" script of previous package if applicable.
> > 3) Execute "preinst" script of new package.
> > 4) Unpack new files and backup old files.
> > 5) Execute "postrm" script of previous package if applicable.
> > 6) Configure the package
> >
> > When installing a newer version of the package, the "postrm" in step 5
> > fails, because the initscript from the new package is extracted in step 4,
> > and update-
> rc.d w/o the "-f"
> > argument exits with a non-zero return code.
> >
> > I would argue that the "updatercd_postrm()" stanza in the
> > update-rc.d.bbclass should include the "-f" flag.
> > (Anyone on the list want to chime in on this?)
> >
> > In the meantime, I have added my own "updatercd_postrm()" stanza in
> > the .bbappend file for the package I'm having issues with, which
> > overrides the one provided by update-rc.d.bbclass.
> >
> > updatercd_postrm() {
> >update-rc.d $D -f ${INITSCRIPT_NAME} remove }
> >
> > --
> > Paul Stath
> > Axxcelera Broadband Wireless
> >
> > >From: Richard Leitner - SKIDATA [richard.leit...@skidata.com]
> > >Sent: Wednesday, November 27, 2013 11:02 AM
> > >To: Stath, Paul
> > >Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> > >Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during
> > >rc.d purge (use -f to force)
> > >
> > >Hi Paul,
> > >good to hear I'm not the only one suffering from this issue...
> > >No, I've received no response on the mailing list yet, but maybe
> > >someone has a hint
> > for us now?
> > >
> > >The only "workaround" I found
