[yocto] Fetcher failure for mercurial repos: 'unknown revision' due to -r in both clone and update?
I've been running into "Fetcher failures" for my recipes using
mercurial recently. They only seem to crop up the first time a package
that comes from a hg repo is fetched.
I believe the issue stems from the combination of the arguments used
by the hg fetcher and the fact that I specified a tag rather than
revision number.
I've included a "trimmed" log at the end of this post, where I've
pruned out useless and personal information. Here are some of of my
comments and questions. I'm no mercurial expert, so please do correct
me if and where I'm wrong!
- Why is GIT_CONFIG being exported for mercurial invocations?
- I think the 'clone -r v1.1.0' followed by the 'update -C -r v1.1.0'
is possibly responsible for the failure.
- In mercurial, the tag is a commit after the revision that's being tagged.
tip 41:58b8f368be68
v1.1.0 40:a925b596c163
v1.0.4 39:6bf84da2571e
- In the above, rev 41 contains the action of tagging 40 as 'v1.1.0'
- Therefore, if we clone the version associated with tag v1.1.0, we
get rev 40 and earlier. At this point, there's no "knowledge" of there
being a 'v1.1.0' tag!
- As such, the 'hg update -C -r v1.1.0' that follows the 'hg clone
-r v1.1.0' fails.
- One possible fix might be to remove the "-r " usage from the hg
fetcher. (lines 101 and 102 in bitbake/lib/bb/fetch2/hg.py)
- A fetch always follows an update to the revision anyway, doesn't
it. (Per comment @ lines 142-143).
- Con: You have to fetch the whole darn repo. It makes sense that we
wouldn't want to do that when we don't have to. :)
- Pro: You'll have the revision you wanted.
- Disclaimer: I'm not familiar enough with this code to know whether
this would cause undesired side effects or break things!
- Workaround: Don't use tags in SRCREV
- This stinks, because I like to write my .bb's as follows, so that
updating a version is just a matter of copy/renaming the .bb
require .inc
PR = "${INC_PR}.0"
SRCREV = "v${PV}"
DEBUG: Fetch: checking for module directory
'/export/home/jon/projects/yocto/poky/build/test/downloads/hg/host/some_dir/my_package'
NOTE: Fetch hg://hg@host/some_dir;module=my_package;protocol=ssh
DEBUG: Running /usr/bin/env hg clone -r v1.1.0
ssh://hg@host/some_dir/my_package my_package
DEBUG: Fetcher accessed the network with the command /usr/bin/env hg
clone -r v1.1.0 ssh://hg@host/some_dir/my_package my_package
DEBUG: Running export HOME="/export/home/jon"; export
SSH_AGENT_PID="1234"; export SSH_AUTH_SOCK=""; export
GIT_CONFIG="/gitconfig"; export PATH="";
/usr/bin/env hg clone -r v1.1.0 ssh://hg@host/some_dir/my_package
my_package
DEBUG: Running /usr/bin/env hg update -C -r v1.1.0
DEBUG: Running export HOME="/export/home/jon"; export
SSH_AGENT_PID="1234"; export SSH_AUTH_SOCK=""; export
GIT_CONFIG="/gitconfig"; export PATH="";
/usr/bin/env hg update -C -r v1.1.0
WARNING: Failed to fetch URL
hg://hg@host/some_dir;module=my_package;protocol=ssh, attempting
MIRRORS if available
DEBUG: Fetcher failure: Fetch command failed with exit code 255, output:
abort: unknown revision 'v1.1.0'!
DEBUG: Python function base_do_fetch finished
DEBUG: Python function do_fetch finished
ERROR: Function failed: Fetcher failure for URL:
'hg://hg@host/some_dir;module=my_package;protocol=ssh'. Unable to
fetch URL from any source.
Thank you,
Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Disabling PREMIRRORS and upstream sources
Is there a simple way to disable the use of PREMIRRORS and MIRRORS within a recipe? (Perhaps the answer here might be worth mentioning in Section 12.23 of the Poky Reference Manual?) My use case for this is the situation where the code hasn't been released yet, so there's no point in checking mirrors. Thank you, Jon ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA issue with custom recipe
> I am trying to create a simple hello world recipe for a helloworld.c
> file. The recipe almost works except it hits a QA issue: WARNING: QA
> Issue: hello: Files/directories were installed but not shipped
>
> The warning leads to a failure in the do_rootfs.
>
> WARNING: QA Issue: hello: Files/directories were installed but not shipped
>/usr
>/usr/bin
> ERROR: Function failed: do_rootfs
> --
>
>
> What am I missing in the recipe?
>
> --
> Regards,
>
> Sean D. Liming
> Owner
> Annabooks
> Cell: 858-774-3176
>
>
> -- next part --
> DESCRIPTION = "Hello World Application"
> LICENSE = "GPL-2"
> LIC_FILES_CHKSUM =
> "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
>
> SECTION = "apps"
>
> SRC_URI = "file:///home/sean/workspace/Hello/HelloYocto.c"
> SRC_URI[md5sum] = "4f5c57b446cc08a7299d4dca58c49cda"
> SRC_URI[sha256sum] =
> "f357d9214f9c585d8b3997c6a3038eb28b218de264a8bb39ae8474949ad2b98d"
>
> S = "${WORKDIR}"
>
> do_compile() {
> ${CC} ${CFLAGS} ${LDFLAGS} /home/sean/workspace/Hello/HelloYocto.c -o
> helloyocto
> }
>
> do_install() {
> install -d ${D}${bindir}
> install -m 0755 helloyocto ${D}{bindir}
> }
>
>
Sean,
I think you need to note which files are installed by the packages
associated with this recipe, via:
FILES_${PN} = "${bindir}"
For more info on these, Check out the FILES and CONFFILES
variables in the Poky Reference Manual. I also found it helpful
to grep around some of the bigger recipes to see how they use
these. (I got a bit tripped up with some libraries with the sonames set!)
Regards,
Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA issue with custom recipe
> > > I am trying to create a simple hello world recipe for a helloworld.c
> > > file. The recipe almost works except it hits a QA issue: WARNING: QA
> > > Issue: hello: Files/directories were installed but not shipped
> > >
> > > The warning leads to a failure in the do_rootfs.
> > >
> > > WARNING: QA Issue: hello: Files/directories were installed but not
> shipped
> > >/usr
> > >/usr/bin
> > > ERROR: Function failed: do_rootfs
> > > --
> > >
> > >
> > > What am I missing in the recipe?
> > >
> > > --
> > > Regards,
> > >
> > > Sean D. Liming
> > > Owner
> > > Annabooks
> > > Cell: 858-774-3176
> > >
> > >
> > > -- next part -- DESCRIPTION = "Hello World
> > > Application"
> > > LICENSE = "GPL-2"
> > > LIC_FILES_CHKSUM =
> > > "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
> > >
> > > SECTION = "apps"
> > >
> > > SRC_URI = "file:///home/sean/workspace/Hello/HelloYocto.c"
> > > SRC_URI[md5sum] = "4f5c57b446cc08a7299d4dca58c49cda"
> > > SRC_URI[sha256sum] =
> > >
> > "f357d9214f9c585d8b3997c6a3038eb28b218de264a8bb39ae8474949ad2b98d"
> > >
> > > S = "${WORKDIR}"
> > >
> > > do_compile() {
> > > ${CC} ${CFLAGS} ${LDFLAGS} /home/sean/workspace/Hello/HelloYocto.c -
> > o
> > > helloyocto }
> > >
> > > do_install() {
> > > install -d ${D}${bindir}
> > > install -m 0755 helloyocto ${D}{bindir} }
> > >
> > >
> >
> > Sean,
> >
> > I think you need to note which files are installed by the packages
> > associated with this recipe, via:
> >
> > FILES_${PN} = "${bindir}"
> >
> > For more info on these, Check out the FILES and CONFFILES
> > variables in the Poky Reference Manual. I also found it helpful
> > to grep around some of the bigger recipes to see how they use
> > these. (I got a bit tripped up with some libraries with the sonames
> > set!)
> >
> >
> > Regards,
> > Jon
>
>
>
> John,
>
> Thank you. The Q/A Warning is gone. That is one step closer, but the
> package
> is still not resolved.
>
> -
> Processing HelloYocto...
>
> Unable to resolve package HelloYocto
>
> ERROR: some packages were missing
>
> ERROR: Function failed: do_rootfs (see
>
> /home/sean/Yocto1.3/n2800/tmp/work/cedartrail-poky-linux/core-image-minimal-
> 1.0-r0/temp/log.do_rootfs.24265 for further information)
>
> --
>
>
>
> Regards,
>
> Sean Liming
> Owner
> Annabooks
> Tel: 714-970-7523 / Cell: 858-774-3176
>
Hi Sean,
What's the name of your hello world recipe? Try naming it hello-world.bb or
hello-world_0.1.0.bb (for a version 0.1.0) and appending hello-world to your
IMAGE_INSTALL.
I believe recipe names must be lower case and use '-' as a separator. An
underscore is used to separate the package name and the version number, as
I've shown above.
It looks like someone posted a great hello world example on the wiki, so be sure
to check that out:
https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_put_my_recipe_into_Yocto.3F
Take a look at meta-skeleton as well. I found that to provide a few very helpful
examples as well. :)
Cheers!
Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA issue with custom recipe
> Jon,
>
> Thanks for your help. It was a path problem with the install call. Digging
> into the working directory the copy from path needs to be specified.
>
> Regards,
>
> Sean Liming
> Owner
> Annabooks
> Tel: 714-970-7523 / Cell: 858-774-3176
>
Hi Sean,
Good find! Sorry, I missed that install issue earlier.
Note that if you're only installing a single file, you can make that a
one liner:
do_install() {
install -D -m 0755 ${S}/helloyocto ${D}/{bindir}/helloyocto
}
Best of luck! :)
- Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] packagegroup-core-boot failure for RTC-less system
Hi all,
I have a MACHINE_FEATURES which *does not* include "rtc", as the platform I
am working on doesn't have an RTC.
The busybox bbappend I'm using (attached below) uses the provided
defconfig, but
disables the HWCLOCK features.
However, my build is failing due to packagegroup-core-boot being unable to
meet the busybox-hwclock dependency. Looking at this line from
packagegroup-core-boot.bb, it seems to me that busybox-hwlock shouldn't be
getting placed in the core-boot's RDEPENDS, given that my MACHINE_FEATURES does
not include "rtc":
${@base_contains("MACHINE_FEATURES", "rtc", "busybox-hwclock", "", d)} \
Any thoughts or tips on debugging this? Perhaps there's somewhere I can stick a
print of MACHINE_FEATURES to verify that it is what I thought I set?
Thank you,
Jon
busybox_1.20.2.bbappend:
PRINC="1"
do_prepare_config_prepend() {
# Back up the defconfig just for later debugging, diffing, etc.
mv ${WORKDIR}/defconfig ${WORKDIR}/defconfig.orig
# We don't have an RTC on our platform, so disable hwclock features.
sed -e 's/\(CONFIG_HWCLOCK\)=y/ #\1 is not set/g'
${WORKDIR}/defconfig > ${WORKDIR}/defconfig.tmp
mv ${WORKDIR}/defconfig.tmp ${WORKDIR}/defconfig
sed -e 's/\(CONFIG_FEATURE_HWCLOCK_.*\)=y/ #\1 is not set/g'
${WORKDIR}/defconfig > ${WORKDIR}/defconfig.tmp
mv ${WORKDIR}/defconfig.tmp ${WORKDIR}/defconfig
}
Build Error:
-
* satisfy_dependencies_for: Cannot satisfy the following
dependencies for packagegroup-core-boot:
*busybox-hwclock *
* opkg_install_cmd: Cannot install package packagegroup-core-boot.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] packagegroup-core-boot failure for RTC-less system
>> I have a MACHINE_FEATURES which *does not* include "rtc", as the platform I
>> am working on doesn't have an RTC.
>>
>> The busybox bbappend I'm using (attached below) uses the provided
>> defconfig, but
>> disables the HWCLOCK features.
>>
>> However, my build is failing due to packagegroup-core-boot being unable to
>> meet the busybox-hwclock dependency. Looking at this line from
>> packagegroup-core-boot.bb, it seems to me that busybox-hwlock shouldn't be
>> getting placed in the core-boot's RDEPENDS, given that my MACHINE_FEATURES
>> does not include "rtc":
>>
>> ${@base_contains("MACHINE_FEATURES", "rtc", "busybox-hwclock", "", d)} \
>>
>>
>> Any thoughts or tips on debugging this? Perhaps there's somewhere I can
>> stick a print of MACHINE_FEATURES to verify that it is what I thought I
>> set?
>
> The way to query the final value of MACHINE_FEATURES is:
>
> bitbake -e | grep ^MACHINE_FEATURES=
>
> FYI though, rtc is a "backfilled" feature - because it was introduced later on
> and we didn't want to break existing machines that do have an RTC and don't
> yet have "rtc" in MACHINE_FEATURES, we added it to MACHINE_FEATURES_BACKFILL.
> In order to prevent it from being backfilled, you can add the following to
> your
> machine config:
>
> MACHINE_FEATURES_BACKFILL_CONSIDERED = "rtc"
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
Hi Paul,
That certainly does the trick!
I didn't realize this "backfill" concept had been added, but now see
it's very well-documented
in the 1.3 manual. Funny how easy it is to find things once you know
what you're looking for... :)
Many thanks!
Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Disabling PREMIRRORS and upstream sources
>>From: yocto-boun...@yoctoproject.org [mailto:yocto- >>boun...@yoctoproject.org] On Behalf Of Jon Szymaniak >>Sent: Monday, December 03, 2012 7:19 AM >>To: yocto@yoctoproject.org >>Subject: [yocto] Disabling PREMIRRORS and upstream sources >> >>Is there a simple way to disable the use of PREMIRRORS and MIRRORS >>within a recipe? >> >>(Perhaps the answer here might be worth mentioning in Section 12.23 of >>the >>Poky Reference Manual?) >> >>My use case for this is the situation where the code hasn't been >>released yet, >>so there's no point in checking mirrors. >> >>Thank you, >>Jon > Isn't this set up in the local.conf file for global use? In the manual I see that there are indeed global options, configured via local.conf. However, I'm wondering if there's a way to denote that PREMIRRORS and MIRRORS should not be used for a *specific recipe* (i.e., only attempt to fetch via what's provided in SRC_URI, and still use the mirrors for other recipes). Perhaps this is a wacky thing to want to do. I just figured there's no sense in hitting all those 404's if I know the code associated with a specific recipe isn't on any of the standard mirrors. > Also, Jon, what documentation > are you referring to here? Are you looking at the latest Yocto Project > documentation (e.g. > http://www.yoctoproject.org/docs/1.4/poky-ref-manual/poky-ref-manual.html > for the Yocto Project Reference Manual?). I think I may have actually been looking at an old manual version, but yes, that'd the documentation I was referring to. It seemed that 12.23, "How does the OpenEmbedded build system obtain source code..." seemed the most relevant to my question. Thanks! Jon ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Disabling PREMIRRORS and upstream sources
>>Hi Jon,
>>
>>Thanks for the clarification on which manual release you were looking
>>at. I am the technical writer for the project so hopefully someone from
>>the team will address the technical aspect of you issue. If there is a
>>way to disable these within a specific recipe then I can get that
>>information into the documentation.
>>
>>Does anyone know if this is possible and how to do it?
>>
>>Scott
>
> I guess the easiest thing would be just to set PREMIRRORS and MIRRORS to
> "" in the recipe.
>
> Cheers,
> Paul
>
> Scott
>
Scott and Paul,
Thank you both very much for your time and help!
I confirmed this does indeed work.
Just to make sure I'm understanding this... so when I place PREMIRRORS = ""
in a recipe, I see that it doesn't affect the associated variables in other
recipes.
Is this because I'm inherently setting up PREMIRRORS_${PN}, which is
initialized with the PREMIRROR defaults (and what was appended and
prepended in the local.conf)?
I'm also guessing that touching PREMIRRORS and MIRRORS within recipes
is generally a bad practice. I'd be curious to hear if my use case
sounds totally
wacky, as I'm still very much getting up to speed on Yocto/OE and best
practices.
Many thanks,
Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove unwanted package from Qt
>
> Hi,
>
> I am compiling Qt-4.8.0 with poky-denzil-7.0 for arm1136 architecture.
>
>
>
> At the time of integrating qt-embedded with rootfs, I am getting qtopia
> directory in usr/share path of rootfs.
>
> I tried removing qtopia directory through qt recipe but ended in
> compilation error. Please suggest any idea to remove qtopia from share
> directory.
>
>
>
> Thanks and Regards
>
> Navani Kamal Srivastava
I ran into this as well after using a bbappend to disable a number of
Qt features, including the building of demos that get staged in the
aforementioned path. In my case, that qtopia directory (and any
subdirectories) wound up either being empty or containing files that
were unnecessary for my build.
My quick and dirty solution was to just to add a install_append()
containing a 'rm -rf ${D}${datadir}/qtopia' in my bbappend. (Be sure
you don't have anything important in there!) I'd be curious to hear if
there's a better approach to this as well...
Regards,
Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove unwanted package from Qt
>>
>> Hi,
>>
>> I am compiling Qt-4.8.0 with poky-denzil-7.0 for arm1136 architecture.
>>
>>
>>
>> At the time of integrating qt-embedded with rootfs, I am getting qtopia
>> directory in usr/share path of rootfs.
>>
>> I tried removing qtopia directory through qt recipe but ended in
>> compilation error. Please suggest any idea to remove qtopia from share
>> directory.
>>
>>
>>
>> Thanks and Regards
>>
>> Navani Kamal Srivastava
>
> I ran into this as well after using a bbappend to disable a number of
> Qt features, including the building of demos that get staged in the
> aforementioned path. In my case, that qtopia directory (and any
> subdirectories) wound up either being empty or containing files that
> were unnecessary for my build.
>
> My quick and dirty solution was to just to add a install_append()
> containing a 'rm -rf ${D}${datadir}/qtopia' in my bbappend. (Be sure
> you don't have anything important in there!) I'd be curious to hear if
> there's a better approach to this as well...
>
> Regards,
> Jon
Oops...just wanted to note the typo in my above response -- I'm not at
a machine where I have access to my recipes.
That should be a do_install_append(), not install_append(). I'd also
double check the qtopia path, as I wrote that from memory, which may
not be reliable. ;)
Apologies,
Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove unwanted package from Qt
On Wed, Jan 16, 2013 at 1:14 PM, Paul Eggleton
wrote:
>
> On Wednesday 16 January 2013 23:26:20 Navani Srivastava wrote:
> > On Thu, Dec 27, 2012 at 11:08 PM, Jon Szymaniak
> wrote:
> > > >> I am compiling Qt-4.8.0 with poky-denzil-7.0 for arm1136
> > > >> architecture.
> > > >>
> > > >> At the time of integrating qt-embedded with rootfs, I am getting
> > > >> qtopia
> > > >> directory in usr/share path of rootfs.
> > > >>
> > > >> I tried removing qtopia directory through qt recipe but ended in
> > > >> compilation error. Please suggest any idea to remove qtopia from
> > > >> share
> > > >> directory.
> > > >
> > > > I ran into this as well after using a bbappend to disable a number
> > > > of
> > > > Qt features, including the building of demos that get staged in the
> > > > aforementioned path. In my case, that qtopia directory (and any
> > > > subdirectories) wound up either being empty or containing files that
> > > > were unnecessary for my build.
> > > >
> > > > My quick and dirty solution was to just to add a install_append()
> > > > containing a 'rm -rf ${D}${datadir}/qtopia' in my bbappend. (Be sure
> > > > you don't have anything important in there!) I'd be curious to hear
> > > > if
> > > > there's a better approach to this as well...
> > >
> > > Oops...just wanted to note the typo in my above response -- I'm not at
> > > a machine where I have access to my recipes.
> > >
> > > That should be a do_install_append(), not install_append(). I'd also
> > > double check the qtopia path, as I wrote that from memory, which may
> > > not be reliable. ;)
> >
> > I tried the same but again ended up with error. As of now i am removing
> > all
> > unwanted things from rootfs by making changes in image_types.bbclass. I
> > am
> > sure this is not the correct way, any ideas are appreciated..
>
> Can I ask both of you exactly how you are getting Qt installed into the
> image?
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
I'm not doing anything too unusual for "installing" Qt. My recipes for
my Qt application simply inherit qt4e, and list qt4-embedded in
DEPENDS.
The only place where I deviated a bit from the norm is that I use a
qt4-embedded_4.8.3.bbappend to set up QT_CONFIG_FLAGS exactly as I
want them, and to rm ${D}/usr/bin/qtopia. Below's my bbappend. I'd be
interested to hear if there's a better way to clean out unneeded
directories from a rootfs (in my case ${D}/usr/bin/qtopia).
DEPENDS = "qt4-tools-native freetype jpeg libpng zlib"
# Override provided recipe and configure Qt4 to...
# - Disable irrelevant functionality and output
# - Disable SQL Plugins
# - Disable unused input/ouput
# - Have keyboard input and mouse input via /dev/input/mice
# - Have Linux framebuffer support
# - Use QML (so we need the declarative engine)
#
# Note, some of these might be extraneous, and this is a work in progress.
# (You've been warned!)
QT_CONFIG_FLAGS = "\
-embedded ${QT_ARCH} -qtlibinfix ${QT_LIBINFIX} \
-release -no-rpath -reduce-relocations -shared -no-exceptions \
-no-mmx -no-3dnow -no-sse -no-sse2 -no-sse3 -no-sse4.1 -no-sse4.2 -no-avx \
-no-glib -no-largefile -no-accessibility -no-openssl -no-gtkstyle \
-no-xcursor -no-xinerama -no-phonon -no-phonon-backend -no-svg -no-webkit \
-no-libmng -no-accessibility -no-qt3support -no-xmlpatterns \
-no-audio-backend -no-gif -nomake examples -nomake demos -no-javascript-jit \
-no-nis -no-cups -no-declarative-debug \
-no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc \
-no-sql-sqlite -no-sql-sqlite2 -no-sql-sqlite_symbian -no-sql-tds \
-no-xkb -no-kbd-tty -no-kbd-qnx -no-mouse-linuxinput \
-no-mouse-tslib -no-mouse-qnx -no-mouse-linuxtp \
-qt-mouse-pc -qt-kbd-linuxinput \
-qt-gfx-linuxfb -qt-gfx-multiscreen \
-depths 8,16,24,32 \
-declarative -script"
PRINC := "${@int(PRINC) + 1}"
# Despite not building them, qt4.inc creates /usr/bin/qtopia/ with
# only demo/ and example/ underneath. Let's get rid of these...
do_install_append() {
rm -rf ${D}/usr/bin/qtopia
}
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove unwanted package from Qt
On Thu, Jan 17, 2013 at 3:19 AM, Eric Bénard wrote:
> Hi Jon,
>
> "inherit qt4e" is enough, no need to add qt4-embedded to DEPENDS.
>
Thanks! This makes sense, as I see this dependency is established in
the first few lines of qt4e.bbclass.
>
> strange, demos and examples are packaged in ${QT_BASE_NAME}-demos and
> ${QT_BASE_NAME}-examples packages so if you find these directories on
> your target, that means you requested qt4-embedded-demos and
> qt4-embedded-examples to be installed in your image.
>
> Are you installing packagegroup-core-qt4e in your image like in
> qt4e-demo-image ? If yes, that's where you pull demos & examples.
>
> To get a minimal image, you could simply have :
> IMAGE_INSTALL += "\
> ${CORE_IMAGE_BASE_INSTALL} \
> you_qt_app \
> some qt4-embedded-fonts or qt4-embedded-plugin you may need
> (check packagegroup-core-qt4e.bb for the exact names) \
> "
> inherit core-image
>
> The Qt libraries your application is linked with will be automatically
> installed and you won't get extra unwanted packages in your image.
>
> Best regards,
> Eric
My IMAGE_INSTALL looks very similar to what you've shown there, which
I based upon what I saw in core-image-minimal. I see that I still have
a task-core-boot lying around, so I need to change that a
packagegroup-core-boot. (IIRC, packagegroup-core-boot PROVIDES
task-core-boot for the time being...)
IMAGE_INSTALL = "
task-core-boot \
my_qt_app \
a_few_unrelated_recipes_that_don't_use_qt \
${ROOTFS_PKGMANAGE_BOOTSTRAP} \
${CORE_IMAGE_EXTRA_INSTALL} \
"
I checked the package list on a running system (opkg list | grep -i
qt). Here's all the installed Qt packages...no qt4-embedded-examples
as far as I see.
libqtcoree4 - 4.8.3-r50.0
libqtdeclarativee4 - 4.8.3-r50.0
libqtguie4 - 4.8.3-r50.0
libqtnetworke4 - 4.8.3-r50.0
libqtscripte4 - 4.8.3-r50.0
libqtsqle4 - 4.8.3-r50.0
Seems strange to me...any thoughts?
Thank you for your time and help!
Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove unwanted package from Qt
On Fri, Jan 18, 2013 at 10:59 AM, Eric Bénard wrote: > Le Fri, 18 Jan 2013 10:25:22 -0500, > Jon Szymaniak a écrit : >> I checked the package list on a running system (opkg list | grep -i >> qt). Here's all the installed Qt packages...no qt4-embedded-examples >> as far as I see. >> >> libqtcoree4 - 4.8.3-r50.0 >> libqtdeclarativee4 - 4.8.3-r50.0 >> libqtguie4 - 4.8.3-r50.0 >> libqtnetworke4 - 4.8.3-r50.0 >> libqtscripte4 - 4.8.3-r50.0 >> libqtsqle4 - 4.8.3-r50.0 >> >> Seems strange to me...any thoughts? > > strange, in a fresh build of danny /usr/share/qtopia is only present in > the following packages : > > ./qt4-embedded-translation-linguist/usr/share/qtopia > ./qt4-embedded-translation-qt/usr/share/qtopia > ./qt4-embedded-translation-qvfb/usr/share/qtopia > ./qt4-embedded-qt3to4/usr/share/qtopia > ./qt4-embedded-translation-qtconfig/usr/share/qtopia > ./qt4-embedded-mkspecs/usr/share/qtopia > ./qt4-embedded-phrasebook-dutch/usr/share/qtopia > ./qt4-embedded-phrasebook-french/usr/share/qtopia > ./qt4-embedded-phrasebook-spanish/usr/share/qtopia > ./qt4-embedded-phrasebook-russian/usr/share/qtopia > ./qt4-embedded-phrasebook-italian/usr/share/qtopia > ./qt4-embedded-phrasebook-polish/usr/share/qtopia > ./qt4-embedded-translation-assistant/usr/sh > ./qt4-embedded-phrasebook-swedish/usr/share/qtopia > ./qt4-embedded-doc/usr/share/doc/qtopia > ./qt4-embedded-translation-designer/usr/share/qtopia > ./qt4-embedded-phrasebook-danish/usr/share/qtopia > ./qt4-embedded-phrasebook-finnish/usr/share/qtopia > ./qt4-embedded-phrasebook-german/usr/share/qtopia > ./qt4-embedded-demos-doc/usr/share/doc/qtopia > ./qt4-embedded-phrasebook-japanese/usr/share/qtopia > ./qt4-embedded-phrasebook-norwegian/usr/share/qtopia > ./qt4-embedded-phrasebook-hungarian/usr/share/qtopia > > can you check in your workdir in packages-split which package includes > this directory ? > > Eric Eric, Sorry for the delay. I did check my packages-split and it was the same as what you listed. Since your email, I had removed my do_install_append() from my qt4-embedded bbappend, blown away build/$MY_DIR/tmp and done a full rebuild. I no longer see the qtopia directory in my images. Perhaps this was a vestige of me experimenting with Qt early on? I guess I'll call it a mystery solved for the time being, but will touch back on the mailing list if I figure out what exactly caused this to be populated in my filesystem. (Unless of course, there were other items you'd like me to check.) Thanks again, Jon ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Finding/Generating Rootfs Package List
Hi all, I generally like to keep a little manifest file with my rootfs images, containing a list of installed packages and their associated versions. On images where I keep package data around, I usually generate this via 'opkg list'. In my current situation, I have a small read-only image where I can't afford to ship pkg data, and wanted to gather this info on the host side of things. I assume this information is tracked somewhere in the poky build directory, but I'm having some trouble finding it. Could someone kindly point me towards this information or the documentation section(s) that I may have overlooked. Thank you! Jon ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Finding/Generating Rootfs Package List
Ross and Martin -- thanks for your quick responses.
I failed to mention that I wanted both the ${PV} and ${PR} for packages, so
unfortunately the *-pkgs.txt files won't suffice.
Is there a particular reason why these files don't contain this
information? I haven't looked into where these are generated, but would
including ${PV} and ${PR} in these be a welcome patch?
Looking at the buildhistory wiki page [1], I see this certainly provides
what I need, and a whole lot more.
[1] https://wiki.yoctoproject.org/wiki/Buildhistory
Thanks again,
Jon
On Thu, Apr 25, 2013 at 10:27 AM, Martin Jansa wrote:
> On Thu, Apr 25, 2013 at 10:10:31AM -0400, Jon Szymaniak wrote:
> > Hi all,
> >
> > I generally like to keep a little manifest file with my rootfs images,
> > containing a list of installed packages and their associated versions.
> On
> > images where I keep package data around, I usually generate this via
> 'opkg
> > list'.
> >
> > In my current situation, I have a small read-only image where I can't
> > afford to ship pkg data, and wanted to gather this info on the host side
> of
> > things. I assume this information is tracked somewhere in the poky build
> > directory, but I'm having some trouble finding it.
> >
> > Could someone kindly point me towards this information or the
> documentation
> > section(s) that I may have overlooked.
>
> buildhistory is what you're looking for
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
--
--
Jon Szymaniak
OpenPGP Key Hosted at the following keyservers:
http://keyserver.ubuntu.com/
http://pgp.mit.edu/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Correctly setting a package-specific RDEPENDS
Hi all,
I recently upgraded to the Dylan (9.0.0) release and am looking to
clean up some QA issues associated with my RDEPENDS variables not
being package-specific.
I'm a bit confused by a couple lines in the manual [1]:
"The names of the variables you list with RDEPENDS must be the names
of other packages as listed in the PACKAGES variable. You should not
list recipe names (PN)."
It makes sense to me that you'd want to set the run-time deps on a
per-package basis to avoid creating false-dependencies. However, I'm
unsure as to how can simply not write RDEPENDS_${PN} in some cases.
Furthermore, I feel like I'm not quite understanding what the
consequences of using RDEPENDS_${PN} are.
Here's an example of what I'm trying to do -- perhaps someone will
catch where I'm getting confused and offer some insight?
Let's say I have a program_a.bb and a program_b.bb. Both are simple
recipes that compile and install ${D}/usr/bin/program_a and
${D}/usr/bin/program_b.
Because program_a forks and execs program_b, but otherwise does not
depend upon it to compile, I thought I should place RDEPENDS_${PN} =
"program_b " in program_a.bb. However, this seems to violate the
aforementioned snippet from the manual.
Thanks!
[1]
http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-RDEPENDS
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Correctly setting a package-specific RDEPENDS
> On Wednesday 05 June 2013 10:53:23 Jon Szymaniak wrote:
>> I recently upgraded to the Dylan (9.0.0) release and am looking to
>> clean up some QA issues associated with my RDEPENDS variables not
>> being package-specific.
>>
>> I'm a bit confused by a couple lines in the manual [1]:
>>
>> "The names of the variables you list with RDEPENDS must be the names
>> of other packages as listed in the PACKAGES variable. You should not
>> list recipe names (PN)."
>
> I think the mention of PN here is confusing. It's trying to explain that you
> should use package names and not recipe names, but perhaps the wording needs
> to be improved.
>
>> It makes sense to me that you'd want to set the run-time deps on a
>> per-package basis to avoid creating false-dependencies. However, I'm
>> unsure as to how can simply not write RDEPENDS_${PN} in some cases.
>> Furthermore, I feel like I'm not quite understanding what the
>> consequences of using RDEPENDS_${PN} are.
>>
>> Here's an example of what I'm trying to do -- perhaps someone will
>> catch where I'm getting confused and offer some insight?
>>
>> Let's say I have a program_a.bb and a program_b.bb. Both are simple
>> recipes that compile and install ${D}/usr/bin/program_a and
>> ${D}/usr/bin/program_b.
>>
>> Because program_a forks and execs program_b, but otherwise does not
>> depend upon it to compile, I thought I should place RDEPENDS_${PN} =
>> "program_b " in program_a.bb. However, this seems to violate the
>> aforementioned snippet from the manual.
>
> That is the expected usage; I guess the manual has confused you. All the QA
> warning is saying is you should do this:
>
> RDEPENDS_${PN} = "somepackage"
>
> and _not_ this:
>
> RDEPENDS = "somepackage"
>
> (The reason being, the latter would add a runtime dependency on "somepackage"
> to every package in the recipe's PACKAGES, which is almost never the desired
> result.)
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
Hi Paul,
That clarifies things greatly. Many thanks!
- Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] do_configure() failure with my qt4-embedded_4.8.0.bbappend
Hi there, I'm working on building some embedded (arm) Qt 4.8.0 applications, and would like to strip out a lot of unused functionality. I have a set of config flags that I've used in the past when configuring Qt outside of the Yocto workflow. As you'll see below, I'm basically just looking for framebuffer, keyboard, mouse and QML support; everything else should be disabled. >From what I understand, the best approach is to leverage the existing qt4-embedded_4.8.0.bb recipe, and override the QT_CONFIG_FLAGS and DEPENDS variables. Here's the qt4-embedded_4.8.0.bbappend I've added to my layer: DEPENDS := "qt4-tools-native freetype jpeg libpng zlib" QT_CONFIG_FLAGS := "-release -no-rpath -reduce-relocations -shared\ -no-mmx -no-3dnow -no-sse -no-sse2 -no-sse3 -no-sse4.1 -no-sse4.2 -no-avx\ -no-glib -no-largefile -no-accessibility -no-openssl -no-gtkstyle -no-exceptions\ -no-xcursor -no-xinerama -no-phonon -no-phonon-backend -no-svg -no-webkit\ -no-libmng -no-accessibility -no-qt3support -no-xmlpatterns\ -no-audio-backend -no-gif -nomake examples -nomake demos -no-javascript-jit\ -no-nis -no-cups -no-declarative-debug\ -no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc\ -no-sql-sqlite -no-sql-sqlite2 -no-sql-sqlite_symbian -no-sql-tds\ -no-xkb -no-kbd-tty -no-kbd-qnx -no-mouse-linuxinput\ -no-mouse-tslib -no-mouse-qnx -no-mouse-linuxtp\ -qt-mouse-pc -qt-kbd-linuxinput\ -qt-gfx-linuxfb -qt-gfx-multiscreen\ -depths 8,16,24,32\ -declarative -script" I see a lot of errors during qt4-embedded_4.8.0's do_configure, where some auto-detection compilation tests are run, for features that aren't relevant or that I've explicitly disabled. (e.g., sse3, PostgreSQL) Ultimately, this stage fails with: "XLib disabled. Basic XLib functionality test failed!" Could someone shed some light on this? I don't intend to use X11, so I'm a bit confused as to why this induces a failure. Being new to Yocto, I suspect that I'm simply going about this incorrectly. Perhaps someone can set me in the right direction? Thank you, Jon ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_configure() failure with my qt4-embedded_4.8.0.bbappend
>> QT_CONFIG_FLAGS := "-release -no-rpath -reduce-relocations -shared\
>> -no-mmx -no-3dnow -no-sse -no-sse2 -no-sse3 -no-sse4.1 -no-sse4.2 -no-avx\
>> -no-glib -no-largefile -no-accessibility -no-openssl -no-gtkstyle
>> -no-exceptions\
>> -no-xcursor -no-xinerama -no-phonon -no-phonon-backend -no-svg -no-webkit\
>> -no-libmng -no-accessibility -no-qt3support -no-xmlpatterns\
>> -no-audio-backend -no-gif -nomake examples -nomake demos
>> -no-javascript-jit\ -no-nis -no-cups -no-declarative-debug\
>> -no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc\
>> -no-sql-sqlite -no-sql-sqlite2 -no-sql-sqlite_symbian -no-sql-tds\
>> -no-xkb -no-kbd-tty -no-kbd-qnx -no-mouse-linuxinput\
>> -no-mouse-tslib -no-mouse-qnx -no-mouse-linuxtp\
>> -qt-mouse-pc -qt-kbd-linuxinput\
>> -qt-gfx-linuxfb -qt-gfx-multiscreen\
>> -depths 8,16,24,32\
>> -declarative -script"
>>
>> I see a lot of errors during qt4-embedded_4.8.0's do_configure, where
>> some auto-detection compilation tests are run, for features that aren't
>> relevant or that I've explicitly disabled. (e.g., sse3, PostgreSQL)
>>
>> Ultimately, this stage fails with:
>> "XLib disabled. Basic XLib functionality test failed!"
>>
>> Could someone shed some light on this? I don't intend to use X11, so I'm
>> a bit confused as to why this induces a failure.
>
> Since you're providing your own value of QT_CONFIG_FLAGS I think you're
> missing -embedded $QT_ARCH and possibly -qtlibinfix ${QT_LIBINFIX} (see
> meta/recipes-qt/qt4/qt4-embedded.inc).
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
Whoops! I most certainly did forget to put the -embedded flag back in after
pruning out that, -platform, -xplatform, -little-endian, etc. from my original
config script. That certainly explains a lot.
Thank you Paul!
- Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_configure() failure with my qt4-embedded_4.8.0.bbappend
>> Since you're providing your own value of QT_CONFIG_FLAGS I think you're
>> missing -embedded $QT_ARCH and possibly -qtlibinfix ${QT_LIBINFIX} (see
>> meta/recipes-qt/qt4/qt4-embedded.inc).
>>
>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre
>
> Whoops! I most certainly did forget to put the -embedded flag back in after
> pruning out that, -platform, -xplatform, -little-endian, etc. from my original
> config script. That certainly explains a lot.
>
> Thank you Paul!
>
> - Jon
It looks like I celebrated a tad too early. Although Qt built
successfully, I'm finding
that I'm a bit confused with qmake and the qt libinfix situation.
>From what I gather looking
at recipes-qt/qt4/* a bit, the point here is to rename libs to differentiate
between the libs generated by the embedded and X11-based recipes, right?
I ended up including -qtlibinfix ${QT_LIBINFIX} in my config flags, and I do
indeed see that my qt4-embbeded libs are now in the form libQt*E.so.
However, my builds are failing because ld complains about not being able to
find QtDeclarative, QtGui, and QtCore.
Looking at the Makefile generated by qmake for one of my little HelloWorld
applications, I see that it seems that qmake did not accounted for the
"E" suffix:
LIBS = $(SUBLIBS) -L$(OE_QMAKE_LIBDIR_QT) -lQtDeclarative -lQtGui
-lQtCore -lpthread
Just as a little experiment, I modified the generated Makefile to add
the "E" suffix,
to each lib and reran bitbake. This succeeded and my Qt app was built.
While I'm sure I could hack in a do_compile_prepend() to address this,
I'm assuming
that it's a configuration mess-up on my end. Given that I only changed
the DEPENDS
and QT_CONFIG_FLAGS in my .bbappend, I can't think of what I might have
neglected here that might be affecting qmake or the mkspec.
Any hints?
Thank you,
Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_configure() failure with my qt4-embedded_4.8.0.bbappend
>>> Since you're providing your own value of QT_CONFIG_FLAGS I think you're
>>> missing -embedded $QT_ARCH and possibly -qtlibinfix ${QT_LIBINFIX} (see
>>> meta/recipes-qt/qt4/qt4-embedded.inc).
>>>
>>> Cheers,
>>> Paul
>>>
>>> --
>>>
>>> Paul Eggleton
>>> Intel Open Source Technology Centre
>>
>> Whoops! I most certainly did forget to put the -embedded flag back in after
>> pruning out that, -platform, -xplatform, -little-endian, etc. from my
>> original
>> config script. That certainly explains a lot.
>>
>> Thank you Paul!
>>
>> - Jon
>
> It looks like I celebrated a tad too early. Although Qt built
> successfully, I'm finding
> that I'm a bit confused with qmake and the qt libinfix situation.
> From what I gather looking
> at recipes-qt/qt4/* a bit, the point here is to rename libs to differentiate
> between the libs generated by the embedded and X11-based recipes, right?
>
> I ended up including -qtlibinfix ${QT_LIBINFIX} in my config flags, and I do
> indeed see that my qt4-embbeded libs are now in the form libQt*E.so.
>
> However, my builds are failing because ld complains about not being able to
> find QtDeclarative, QtGui, and QtCore.
>
> Looking at the Makefile generated by qmake for one of my little HelloWorld
> applications, I see that it seems that qmake did not accounted for the
> "E" suffix:
>
> LIBS = $(SUBLIBS) -L$(OE_QMAKE_LIBDIR_QT) -lQtDeclarative -lQtGui
> -lQtCore -lpthread
>
> Just as a little experiment, I modified the generated Makefile to add
> the "E" suffix,
> to each lib and reran bitbake. This succeeded and my Qt app was built.
>
> While I'm sure I could hack in a do_compile_prepend() to address this,
> I'm assuming
> that it's a configuration mess-up on my end. Given that I only changed
> the DEPENDS
> and QT_CONFIG_FLAGS in my .bbappend, I can't think of what I might have
> neglected here that might be affecting qmake or the mkspec.
>
> Any hints?
>
> Thank you,
> Jon
Sorry for the monologue folks, twas a small matter of ignorance. ;)
Just to create a trail of breadcrumbs, the issue was that I was inheriting
qmake2 in my app's recipe. I should have been inheriting qt4e. I see
that this sets up QT_LIBINFIX as well as a number of other items.
See meta/classes/qt4e.bbclass.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH] firmware.inc: Fetch a zip instead of cloning a git repo
GitHub provides this ability to download repository contents at
a specified changeset as a zip file. This is generally *much* quicker
than fetching the entire git repository.
This resolves some do_fetch() failures I've seen for bcm2835-bootfiles
in which the clone operation takes a very long time, and the connection
eventually hangs and errors out.
Signed-off-by: Jon Szymaniak
---
recipes-bsp/common/firmware.inc | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
index ad3176a..5830bb0 100644
--- a/recipes-bsp/common/firmware.inc
+++ b/recipes-bsp/common/firmware.inc
@@ -1,8 +1,10 @@
RPIFW_SRCREV ?= "e42a747e8d5c4a2fb3e837d0924c7cc3936a"
RPIFW_DATE ?= "20150206"
-RPIFW_SRC_URI ?=
"git://github.com/raspberrypi/firmware.git;protocol=git;branch=master"
-RPIFW_S ?= "${WORKDIR}/git"
+RPIFW_SRC_URI ?=
"https://github.com/raspberrypi/firmware/archive/${RPIFW_SRCREV}.zip";
+RPIFW_S ?= "${WORKDIR}/firmware-${RPIFW_SRCREV}"
SRC_URI = "${RPIFW_SRC_URI}"
+SRC_URI[md5sum] = "a0cd8bc3a82fa708e26da62350fcf485"
+SRC_URI[sha256sum] =
"eebf3bbe2fda533da4b44e713090428e6c14306445543243ae03bca774894840"
SRCREV = "${RPIFW_SRCREV}"
PV = "${RPIFW_DATE}"
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] firmware.inc: Fetch a zip instead of cloning a git repo
On Fri, Jun 26, 2015 at 4:31 AM, Burton, Ross wrote: > > On 26 June 2015 at 05:16, Jon Szymaniak wrote: > >> GitHub provides this ability to download repository contents at >> a specified changeset as a zip file. This is generally *much* quicker >> than fetching the entire git repository. >> > > Github also can and will regenerate these tarballs whenever it feels like > it, so you'll need to periodically update the checksums. Obviously as > existing developers will tend to have the tarballs cached locally, it can > be a while before this failure is reported back. > > A better solution might be to add support for "depth" to the git fetcher, > so you can grab just the commit you are interested in instead of the entire > repository. > > Ross > Hi Ross, Excellent point about the regeneration potentially yielding different checksums. I suppose they could change the compression level they use at any moment in time... I'll look into adding that depth support to the fetcher, as that doesn't look too hard at all. I'm open to other suggestions as well, as this was just a first stab at it. I've been seeing that cloning this git repo containing binary firmware blobs takes an absurd amount of time, if it even finishes at all successfully. Cheers, Jon -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] firmware.inc: Fetch a zip instead of cloning a git repo
On Fri, Jun 26, 2015 at 10:19 AM, Burton, Ross wrote: > > > On 26 June 2015 at 15:16, Jon Szymaniak wrote: > >> I'm open to other suggestions as well, as this was just a first stab at >> it. I've been seeing that cloning this git repo containing binary firmware >> blobs takes an absurd amount of time, if it even finishes at all >> successfully. >> > > I believe github offers hosting of "release" tarballs too, so upstream > could take advantage of that. Having verified checksums of firmware is > useful from a security point of view as you can't really inspect the > sources for it... > That's actually what I looked for first, and definitely would use that if it were available. Generally when you apply a tag or manually create a release on GitHub, and etnry under "Tags" or "Releases" is created. It will automatically provide a zip and/or tar.gz of the repo sources -- I suspect this would suffer from the same risk of changing checksums that you expressed concern over. Therefore, it would require the upstream maintainer to upload a specific .tar.gz, preferably with .sha256sum and .md5sum files. Back to the git depth point... why is "--depth 1" not the default for all cases? Could anyone elaborate on some use cases where we'd actually want the entire history for builds? - Jon -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] firmware.inc: fetch from SVN instead of Git
Hi all, > > > > So there is no support for depth clones until 2.5.0? I didn't really > > understand. > > Well, shallow clones are supported but only for branch tips, which is > not what we need. This feature for shallow cloning a specific revision > is available only in git 2.5.0+. Also, this feature needs a server-side > configuration option to be enabled, in order to work properly. > > Regards, > Nikolay > I'd argue that this whole issue with the whole meta-raspberrypi firmware.inc download is more than just slow, inconvenient download. I've left builds running all night (8+ hours on a 30Mib/s residential link) that just hang on this, usually timing out. I initially thought it was just me, but am hearing others confirm this as well. As such, I just wanted to continue this conversation. It sounds like git fetch's --depth is the best option on the table, but has the issues Nikolay has described. What are your thoughts on the following? (1) We create a git-native and build a version that supports this the fetch depth? I suspect this could be made to work, but haven't dug into what dependencies git may have and how that would play out on various LTS distros. My knee-jerk is that has too high of a risk/benefit ration, given that we're talking about 1 repo. (2) We update the git fetcher to check the git version and support a depth= option if the git version is sufficient. If it is not, we spit out a warning and fall back to the current behavior. Neither (1) nor (2) address Nikolay's point that --depth requires server-side support. However, I'd argue this is something you'd be testing and verifying when writing the recipe. Is this a reasonable assertion? How likely is it that a server supporting this would suddenly be re-configured? (3) We request that the upstream maintainer of meta-raspberrypi use the GitHub Release feature [a] to post a tarball of a known checksum at somewhat regular intervals. I'm told by a few package maintainers that while the tarballs that it generates for specific changesets are subject to change, that the tarballs it autogenerates when using its Releases feature do not. However, I have not confirmed this. If this is false, then one can upload a tarball with known checksums to the release as an attachment; I would be *shocked* if they touch your attachments. While (3) is a nice "not our problem" solution, I think (2) might have some benefits for other recipes later. Any other ideas? Best regards, Jon [a] https://help.github.com/articles/creating-releases/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Upstream U-Boot fetch failure (Jethro)
Hi all, When fetching from upstream U-Boot, I am encountering an initial fetch failure that "breaks" the current build. After this initial failure, successive executions of the recipe allows it to continue. The minimal recipe for me to reproduce this is a simple two liner. u-boot_2016.01.bb: --- require recipes-bsp/u-boot/u-boot.inc SRCREV = "fa85e826c16b9ce1ad302a57e9c4b24db0d8b930" It appears do_fetch() fails at the following command: git -c core.fsyncobjectfiles=0 branch --contains fa85e826c16b9ce1ad302a57e9c4b24db0d8b930 --list master 2>/dev/null | wc -l Manually diving into the associated work directory, I find the git/ directory exists, but is completely empty. If I instead use bitbake -c devshell virtual/bootloader, I see that an additional do_unpack() step is first executed, resulting in the work dir's git/ directory being populated and allowing the aforementioned command to properly output a "1" as expected by the fetcher. At this point successive attempts to build the recipe succeed. Would someone mind letting me know if this can be reproduced, and whether they can make heads or tails of this? Thanks, Jon -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Altera Cyclone V u-boot-spl with meta-altera
> Is there a way to produce a signed u-boot-spl image during the build, that > can be used directly on the target without using the EDS? > > If you upgrade to the U-Boot 2016.01 (or maybe even earlier?), mkimage actually supports adding the Bootrom signature to the SPL for you. The current makefile is kind enough to concatenate the U-Boot SPL and its DTS for you, and then run mkpimage to create an 'spl/u-boot-spl-dts.sfp' file [1]. If that doesn't work for you, you might find [2] to be useful. The bootrom "signature" is simple enough to implement in a do_compile_append() or custom task. [1] http://git.denx.de/?p=u-boot.git;a=blob;f=Makefile;h=c9c2cbedc641853c7886ffb023e5798362152899;hb=6905f4d3c7be46fed4859f51f0a8f9a1107c22e7#l1012 [2] https://github.com/maximeh/mkpimage -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Altera Cyclone V u-boot-spl with meta-altera
> > > If you upgrade to the U-Boot 2016.01 (or maybe even earlier?), mkimage > actually supports adding the Bootrom signature to the SPL for you. The > current makefile is kind enough to concatenate the U-Boot SPL and its DTS > for you, and then run mkpimage to create an 'spl/u-boot-spl-dts.sfp' file > [1]. > > If that doesn't work for you, you might find [2] to be useful. The > bootrom "signature" is simple enough to implement in a do_compile_append() > or custom task. > > [1] > http://git.denx.de/?p=u-boot.git;a=blob;f=Makefile;h=c9c2cbedc641853c7886ffb023e5798362152899;hb=6905f4d3c7be46fed4859f51f0a8f9a1107c22e7#l1012 > > [2] https://github.com/maximeh/mkpimage > > > Typo correction: u-boot-with-spl-dtb.sfp -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] wic: Setting partition id value?
On Feb 10, 2016 12:24 PM, "Usman, Fahad" wrote: > > Hi, > Is there a way to create a partition with an arbitrary partition id, using wic tool. We want to create a disk image using wic for Altera Cyclone V. It require the partition id to be set to a particular hex value for the partition it reads the boot loader binary from. The partition id does get set automatically to the correct value depending on the value of fstype (eg. 0x83 for ext3 or 0x0c for fat32), but I couldn't find a way to set it to an arbitrary value. > I ran into this problem as well, but with parted. My hack was to use dd to write the correct type ID into the image's MBR after I finished creating the partitions on the image file. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] qemu-native build fails on sumo due to missing capstone.h
When attempting to build core-image-minimal on sumo (@b369e61) with a
largely default local.conf, I'm experiencing qemu-native build failures due
to what appear to be an include path issue.
Below is one of the failures -- those not listed here also pertain to a
missing capstone.h.
| CC aarch64-softmmu/monitor.o
| In file included from /snip/build/yocto/sumo/rpi/tmp
/work/x86_64-linux/qemu-native/2.11.1-r0/qemu-2.11.1/disas.c:9:0:
| /snip/build/yocto/sumo/rpi/tmp/work/x86_64-linux/qemu-native
/2.11.1-r0/qemu-2.11.1/include/disas/capstone.h:6:10: fatal error:
capstone.h: No such file or directory
| #include
| ^~~~
| compilation terminated.
In the qemu-native build directory, the config.log shows an "
-I/usr/include/capstone" parameter being used during compilation, despite
other -I parameters using ${prefix} correctly.
capstone is pulled into the qemu source tree as a git submodule, and has a
CMake-based build -- so I'm guessing this is the result of not providing
prefix information to the CMake build? However, I'm honestly not sure why
there's a dependency on the capstone disassembler at this point, and
whether the Yocto use-case warrants even enabling support for it.
Adding --disable-capstone to the qemu.inc EXTRA_OECONF definition seemed to
address the build failure, but I haven't tried any QEMU targets yet.
I still need to dig into this a bit further, but just wanted to check in
before I go too far down the rabbit hole... this strikes me as something
that would have broken the nightly builds and therefore might just be an
issue on my end somehow.
Thanks,
Jon Szymaniak
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security] buck-security not found in STAGING_BINDIR_NATIVE
I'm working with the rocko branch of the meta-security layer [1], with the
latest poky rocko branch HEAD on an Ubuntu 17.10 machine (technically an
"untested" distro but otherwise fine with Rocko the past).
>From my understanding, all that should be required to run the buck-security
after an image build is adding INHERIT += "check_security" to local.conf. I see
that check_security.bbclass [2] already takes care of appending itself to
EXTRA_IMAGEDEPENDS.
However, when building an image (e.g. core-image-minimal),
check_security.bbclass is failing to find buck-security in
${STAGING_BINDIR_NATIVE}, as indicated by the following error message:
${TMPDIR}/work/raspberrypi0_wifi-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/run.check_security.24976:
112:
${TMPDIR}/work/raspberrypi0_wifi-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/run.check_security.24976:
${TMPDIR}/work/raspberrypi0_wifi-poky-linux-gnueabi/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/buck-security:
not found
The above makes it clear what ${STAGING_BINDIR_NATIVE} expands to;
buck-security is indeed not present in this location.
My logs indicate that when buck-security-native recipe's do_install() is
executed [3], ${D} and ${bindir} are defined as follows:
D: ${TMPDIR}/work/x86_64-linux/buck-security-native/0.7-r0/image
bindir:
${TMPDIR}/work/x86_64-linux/buck-security-native/0.7-r0/recipe-sysroot-native/usr/bin
buck-security also appears to be present in the following location:
${TMPDIR}/sysroots-components/x86_64/buck-security-native/usr/bin/buck-security
After going through the manuals, I'm still a little unclear about when exactly
buck-security-native's files should be copied or linked into the image's
respective sysroot (presumably, during do_populate_sysroot?), and where the
breakdown is happening here.
If anyone else is able to reproduce this or provide some assistance in
resolving or just debugging it, I'd greatly appreciate it.
Thank you,
Jon Szymaniak
Links:
[1] https://git.yoctoproject.org/cgit/cgit.cgi/meta-security/
[2]
https://git.yoctoproject.org/cgit/cgit.cgi/meta-security/tree/classes/check_security.bbclass
[3]
https://git.yoctoproject.org/cgit/cgit.cgi/meta-security/tree/recipes-security/buck-security/buck-security_0.7.bb#n51
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security] buck-security not found in STAGING_BINDIR_NATIVE
On Fri, Jun 1, 2018 at 11:34 AM, Jon Szymaniak wrote: > From my understanding, all that should be required to run the buck-security > after an image build is adding INHERIT += "check_security" to local.conf. I > see > that check_security.bbclass [2] already takes care of appending itself to > EXTRA_IMAGEDEPENDS. To get this working I ended up instead inheriting check_security in the image recipe, and explicitly add buck-security-native to the image recipe's DEPENDS. The latter seems to be required -- otherwise I run into the same failure mode. Nonetheless, I'm still digging through the do_prepare_recipe_sysroot and do_populate_sysroot implementations to try to understand why check_security.bbclass's assignment to EXTRA_IMAGEDEPENDS does not seem sufficient to get buck-security installed into the image receipe's sysroot. Is there some caveat or subtlety with respect when a recipe's sysroot-related tasks run and aggregate dependencies, versus when the contents of EXTRA_IMAGEDEPENDS are appended to a recipe's set of dependencies? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security] buck-security not found in STAGING_BINDIR_NATIVE
I'm working with the rocko branch of the meta-security layer [1], with the
latest poky rocko branch HEAD on an Ubuntu 17.04 machine (technically an
"untested" distro but otherwise fine in the past).
>From my understanding, all that should be required to run the buck-security
after an image build is adding INHERIT += "check_security" to local.conf. I
see that check_security.bbclass [2] already takes care of appending itself
to EXTRA_IMAGEDEPENDS.
However, when building an image (e.g. core-image-minimal),
check_security.bbclass is failing to find buck-security in
${STAGING_BINDIR_NATIVE}, as indicated by the following error message:
${TMPDIR}/work/raspberrypi0_wifi-poky-linux-gnueabi/core-ima
ge-minimal/1.0-r0/temp/run.check_security.24976:
112: ${TMPDIR}/work/raspberrypi0_wifi-poky-linux-gnueabi/core-ima
ge-minimal/1.0-r0/temp/run.check_security.24976:
${TMPDIR}/work/raspberrypi0_wifi-poky-linux-gnueabi/core-im
age-minimal/1.0-r0/recipe-sysroot-native/usr/bin/buck-security: not found
The above makes it clear what ${STAGING_BINDIR_NATIVE} expands to;
buck-security is indeed not present in this location.
My logs indicate that when buck-security-native recipe's do_install() is
executed [3], ${D} and ${bindir} are defined as follows:
D: ${TMPDIR}/work/x86_64-linux/buck-security-native/0.7-r0/image
bindir:
${TMPDIR}/work/x86_64-linux/buck-security-native/0.7-r0/recipe-sysroot-native/usr/bin
buck-security also appears to be present in the following location:
${TMPDIR}/sysroots-components/x86_64/buck-security-native/usr/bin/buck-security
After going through the manuals, I'm still a little unclear about when
exactly buck-security-native's files should be copied or linked into the
image's respective sysroot (presumably, during do_populate_sysroot?), and
where the breakdown is happening here.
If anyone else is able to reproduce this or provide some assistance in
resolving or just debugging it, I'd greatly appreciate it.
Thank you,
Jon Szymaniak
References:
[1] https://git.yoctoproject.org/cgit/cgit.cgi/meta-security/
[2] https://git.yoctoproject.org/cgit/cgit.cgi/meta-security
/tree/classes/check_security.bbclass
[3] https://git.yoctoproject.org/cgit/cgit.cgi/meta-security/tree/recipes-
security/buck-security/buck-security_0.7.bb#n51
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] qemu-native build fails on sumo due to missing capstone.h
On Fri, Jun 1, 2018 at 1:00 AM, Jon Szymaniak wrote:
> When attempting to build core-image-minimal on sumo (@b369e61) with a
> largely default local.conf, I'm experiencing qemu-native build failures due
> to what appear to be an include path issue.
>
> Below is one of the failures -- those not listed here also pertain to a
> missing capstone.h.
>
> | CC aarch64-softmmu/monitor.o
> | In file included from
> /snip/build/yocto/sumo/rpi/tmp/work/x86_64-linux/qemu-native/2.11.1-r0/qemu-2.11.1/disas.c:9:0:
> |
> /snip/build/yocto/sumo/rpi/tmp/work/x86_64-linux/qemu-native/2.11.1-r0/qemu-2.11.1/include/disas/capstone.h:6:10:
> fatal error: capstone.h: No such file or directory
> | #include
> | ^~~~
> | compilation terminated.
>
> In the qemu-native build directory, the config.log shows an "
> -I/usr/include/capstone" parameter being used during compilation, despite
> other -I parameters using ${prefix} correctly.
>
> capstone is pulled into the qemu source tree as a git submodule, and has a
> CMake-based build -- so I'm guessing this is the result of not providing
> prefix information to the CMake build? However, I'm honestly not sure why
> there's a dependency on the capstone disassembler at this point, and whether
> the Yocto use-case warrants even enabling support for it.
>
> Adding --disable-capstone to the qemu.inc EXTRA_OECONF definition seemed to
> address the build failure, but I haven't tried any QEMU targets yet.
>
> I still need to dig into this a bit further, but just wanted to check in
> before I go too far down the rabbit hole... this strikes me as something
> that would have broken the nightly builds and therefore might just be an
> issue on my end somehow.
>
> Thanks,
> Jon Szymaniak
Sorry to be a bother -- just wanted to bump this.
Happy to work on a patch, but just wanted a sanity check to confirm
that other folks are seeing this too.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] qemu-native build fails on sumo due to missing capstone.h
On Thu, Jun 14, 2018 at 11:43 Khem Raj wrote: > Do you have capstone development headers/libs installed on your build host ? > No, and I understand that's an easy thing to address on the build host. However, I don't think this should be necessary build host dependency. QEMU includes the capstone codebase as a git submodule, so everything that's needed is there. Maybe it's just a matter of tweaking the recipe to set CMAKE_INSTALL_PREFIX appropriately so that when the build dives down into the capstone directory, this points to the correct prefix? It looks like the inclusion and use of capstone is new, as of the QEMU version included with sumo. (i.e. This appears not to be the situation with the version used in rocko and pyro). -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Build failure when BUILDHISTORY_FEATURES includes "package"
Hi all,
I'm encountering the following error, which I can reproduce with qemu
targets, core-image-minimal, a default bblayers.conf, and the
following additions to an otherwise default local.conf:
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "0"
BUILDHISTORY_FEATURES = "package"
ERROR: core-image-minimal-dev-1.0-r0 do_packagedata_setscene: The
recipe core-image-minimal-dev is trying to install files into a shared
area when those files already exist. Those files and their manifest
location are:
${TMPDIR}/pkgdata/qemux86-64/runtime/core-image-minimal-dev
(matched in manifest-qemux86_64-core-image-minimal.packagedata)
Please verify which recipe should provide the above files.
My build host is XUbuntu-17.10 -- not officially supported so I
understand my mileage may vary. If no one else is seeing this, I can
follow up with some logs, try a supported LTS next week, and try to
report back with a root cause.
Mostly just trying to confirm this isn't PEBKAC ... ;)
Cheers,
Jon
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] qemu-native build fails on sumo due to missing capstone.h
On Thu, Jun 14, 2018 at 14:18 Khem Raj wrote: > On Thu, Jun 14, 2018 at 9:56 AM Jon Szymaniak > wrote: > > > > On Thu, Jun 14, 2018 at 11:43 Khem Raj wrote: > > > Do you have capstone development headers/libs installed on your build > host ? > > > > > > > No, and I understand that's an easy thing to address on the build host. > > > > However, I don't think this should be necessary build host dependency. > > QEMU includes the capstone codebase as a git submodule, so everything > > that's needed is there. > > > > Maybe it's just a matter of tweaking the recipe to set > > CMAKE_INSTALL_PREFIX appropriately so that when the build dives down > > into the capstone directory, this points to the correct prefix? > > > > It looks like the inclusion and use of capstone is new, as of the QEMU > > version included with sumo. (i.e. This appears not to be the situation > > with the version used in rocko and pyro). > > Least intrusive approach would be to disable it if its not something you > depend on. Makes sense, thank you. Two workarounds that worked for me were either adding qemu-native to ASSUME_PROVIDED or appending “--disable-capstone” to qemu’s EXTRA_OECONF. I’ll try to follow up with a patch to the recipe in oe-core, unless you suspect that the source of this is merely something on my end. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Tracking changes in image
On Mon, Aug 27, 2018 at 10:13 Bryan Fishell wrote: > Hi, > I want to be able to track different parts of my image, accessible from > within userspace so I can programmatically (via an environment variable or > something) what version of my patches have been applied. Ultimately, I want > to be able to answer questions from the field to know 'what changed' in a > deployed image. Is there already a method to do this? For example, our > project has u-boot, a zImage and rootfs. Is there a way to tell the patched > version (from my layer) for each of those so I can connect what is in the > field to what is in my layer in version control? > > Thanks in advance > > -- > Take a look at the documentation for the Build History feature. I think that may be a good starting point for you. https://www.yoctoproject.org/docs/2.5.1/dev-manual/dev-manual.html#maintaining-build-output-quality Ultimately, the Build History provides you with the "what changed" in terms of build artifacts, which you can then trace back to individual packages and recipes. On the other hand, version control of your own Yocto/OE layers (which has nothing to do with build history) should capture the "why was X changed". Of course, this requires that your organization uses version control in a disciplined manner for any layer metadata they maintain. Between these two, you should be able to develop a pretty clear picture of the "what and why" with respect to changes in an image. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Security updates question
Hi Brian, On Fri, Sep 7, 2018 at 3:36 PM Khem Raj wrote: > Hi Brian > > On Fri, Sep 7, 2018 at 1:25 PM Brian Smucker wrote: > > > > Hello all, > > > > We have a device whose image is built using an older yocto image. It is > > based on yocto Danny, if I recall correctly. > > > > How do users of yocto handle the need occasionally to update one or more > > component packages to deal with security vulnerabilities? > > > > I am not a yocto expert and I was hoping there would be a clear way > > forward here. > > > > Migrating all our recipes to the latest version of yocto probably should > > be done, but it would involve weeks of pain. I know, I started to do it > > sometime back. > > > > So that is one option, but a very unattractive one at the moment. > > > > When we jumped into using Yocto, I was hoping that there would be a > > clear answer to this, but I have been frustrated. Perhaps there is a > > clear answer, but it's outside of what I know. > > > > What are my options and the tradeoffs of each? > > yocto project provided infra to build distributions. so you would have > either built your own distribution or procured it from someone else e.g. > OSVs, if its third party the they generally have security update schedules > that you can work with. > > If you build your own distro then you have freedom to make changes > and patch the security vulnerability and deploy it. > community maintains releases for quite some time and you can just > cherry-pick the point releases which primarily get security fixes. > danny is an old release and is not currently supported in community > > https://wiki.yoctoproject.org/wiki/Releases > > so you can still check if needed fixes are there in danny and build it. > you can also work with some OE/yocto consultants to get this done > for danny > > There are also binary feed based distributions like angstrom which can > provide prebuilt packages ( ipks) but they also have support schedule > and I am sure for angstrom danny based feeds are not updated. > > Thanks > -Khem > To further expand on Khem's thoughts -- you can find some system update options compared/contrasted here: https://wiki.yoctoproject.org/wiki/System_Update In general, if you track changes made to a supported release branch, the commit logs tend to make it quite clear which changesets are addressing one or more CVEs. The Build History feature [1] can help you make sense of everything that's in your image, and the cve-check BitBake class [2] can help supplement whatever processes you use to track relevant CVEs. [1] https://www.yoctoproject.org/docs/2.5.1/dev-manual/dev-manual.html#maintaining-build-output-quality [2] https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/cve-check.bbclass If you’re designing your own update mechanism, or even evaluating some options, there are plenty of important factors to consider. Each of these may involve a number of critical design decisions, which must consider the constraints, operating environment, and needs of your specific product. For example, a mechanism supporting over-the-air updates to a fleet of maritime vessels over a low-data-rate wireless connection will likely differ from one that is intended for IoT devices in the home. Just a few important factors to consider include: - Authenticity: How do you ensure that someone has not maliciously tampered with an update? Typically, this is implemented using a digital signature computed using an asymmetric cryptographic algorithm. This signature must be verified prior to parsing or otherwise processing the contents of an update. Devices would need to have a priori knowledge of the public portion of the signing key, or that of a certificate authority that will have signed any newly supplied signing certificates. I’m certainly biased, but strongly believe that this is the sort of thing you’ll want to have reviewed by a third party, as there are plenty of potential pitfalls. - Rollback Protection: How can you prevent an attacker from reverting a device to an earlier, vulnerable state? If you have a business case for allowing customers to downgrade firmware, is it possible to maintain a whitelisted set of downgrade options? - Fault Tolerance: What happens if a failure (e.g. loss of power) occurs during an update? How can the system detect whether or not an update has been successfully applied, and recover from a failure? For devices with ample storage media, a popular option seems to be an A/B partition layout, in which an inactive system partition is updated and then switched to on reboot, after the update is determined to have been applied successfully. Any ability to track repeated boot failures could be leveraged to boot a recovery image, which of course should enforce the authenticity & rollback restrictions outlined above. While I certainly understand your frustration, I think one thing to recognize is how challenging of a task it would be to have a one-size-fits-all solution maintained by the
Re: [yocto] Security updates question
Hi Brian, On Sat, Sep 8, 2018 at 6:20 PM Brian Smucker wrote: > Jon, > > I do appreciate your insights and I am aware of some of the update > mechanisms that are out there. At the moment we don't have a need for > that. The need at this time is a totally new image, identical to the > working image we have been using, except with an updated web server > package. For the present we will use our manual update mechanism to > update select devices on an as-needed basis. > > So I am not implying by my question that I think that Yocto should have > a way to do that kind of updating. I agree that it is out of the scope > of the Yocto build system. And the update mechanism itself was in no > case what prompted the question in the first place. > > The question was: How do people/companies deal with the problem of > needing a new version of an existing package in a working image based on > an old version of Yocto? > > Thanks again for your reply. > > Brian > > My sincere apologies for completely misunderstanding your question. I've CC'd the mailing list in this response, just in an attempt to help steer further discussion back on course, after I wandered off. :) Here's my attempt at more useful questions and comments, at least. 1) How have the maintainers of the upstream software in question resolved the vulnerability? 1a) Is there a single patch, or a manageable number of patches, that you could apply to address the vulnerability? If so, perhaps you could use a .bbappend file [1] in your layer to append patches to SRC_URI. 1b) Take a look at how patches are backported in release branches (e.g. [2]) for some inspiration. 2) In the case where the version you're on does not have an easily applied patch available, is it possible to simply pull in a recipe from a newer version of Yocto into your own layer(s)? 2a) Depending on the software, this might lead you down a dependency rabbit hole, and might not be viable. 2b) If this is possible, I wonder if it would be sane to maintain your own layer of updated recipes you're transitioning to, as not to clutter whatever layer(s) you use for your organization. Ideally, once you reach a point where you could fully switch to a newer Yocto release, you could just drop this temporary layer from your bblayers.conf and track a maintained release. [1] https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-bbappend-files [2] https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=rocko&id=b33d89d5ea8604657a59b83a30c3374079c34fd2 Best regards, Jon -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NVIDIA or AMD accelerated graphics on x86 or x86-64 machine architecture
On Fri, Oct 26, 2018 at 15:51 Matt Ervin wrote: > I’m creating a poky (sumo branch) based OS image for x86_64 PC hardware. > It’s an embedded device that is essentially a desktop PC in a box with > additional features. My device requires accelerated graphics (either NVIDIA > or AMD, not Intel) and I’m having difficulty identifying which layer and > recipe to use for either device. Are there any recipes that encapsulate the > NVIDIA Linux desktop binary drivers for x86? If not then are there any > consultants willing to sell me some time to help me create one, or to > create one for me? I did some google searching and found a layer from > OakLabs, but it doesn’t work (at least not with the sumo branch). The > README file in the recipe also states that it’s likely to break the build, > and it did produce errors for me. I’m not familiar with AMD on Linux so I > don’t know if the xf86-video-ati recipe in the meta-oe layer provides > accelerated desktop drivers or, if it does, which AMD devices it supports. > I’m obviously very new to Yocto so any guidance is greatly appreciated. > > > > - Matt > Hi Matt, Any chance you share a bit more info including: 1) Which OakLabs layer you using, and what exactly the failures messages are? 2) Which NVIDIA and AMD devices you need to support? Specifically which drivers do you want installed? Thanks, Jon -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Making a script into an executable binary in yocto
Could you provide a bit more context about your particular use-case and need to do this? i.e. Why is deployment of the existing script insufficient? I know this isn’t addressing your underlying question, but just want to see if perhaps an alternative solution may be a better one for you. On Sun, Jan 6, 2019 at 13:12 nishant poorswani wrote: > Hi, I wanted to know which is the best way of converting a bash script > into an executable binary in yocto. One way to do this is to add a recipe > for shc( script compiler) in yocto and then use the shc for compiling it in > another recipe. Is there any other way to achieve this ? Any suggestions > would be deeply appreciated. > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
