[yocto] [PATCH] [rrs] Show the 'Upstream version' column only when relevant

[Belen Barros Pena]

From: Belen Barros Pena 

Currently the recipes table always shows the 'Upstream version' column.
However, for recipes up-to-date, this column is irrelevant, since for such
recipes 'version' always equals 'upstream version'.

Since the vast majority of the recipes are up-to-date, when you are
showing all the recipes the 'upstream version' column is also pretty
useless.

The column is only really relevant when you are looking at recipes
with status 'not updated' or 'can't be updated'. I would have thought
there would be nothing to show in the 'Upstream version' column for
recipes with status 'Unknown', but it turns out some of those do have
an upstream version value, that I thought might be useful to the
maintainer somehow.

So, this patch hides the 'Upstream version' column whenever you are
looking at all the recipes or up-to-date recipes; and shows it when
you select any of the other recipe statuses

Signed-off-by: Belen Barros Pena 
---
 templates/rrs/recipes.html | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/templates/rrs/recipes.html b/templates/rrs/recipes.html
index be2a3a5..96a3bbc 100644
--- a/templates/rrs/recipes.html
+++ b/templates/rrs/recipes.html
@@ -234,6 +234,12 @@ $(document).ready(function() {
 $('.summary_column').show()
 }
 
+if (upstreamStatus == 'Up-to-date' || upstreamStatus == 'All') {
+$('.upstream_version_column').hide();
+} else {
+$('.upstream_version_column').show();
+}
+
 if (upstreamStatus == 'All') {
 upstreamStatusFilter = ''
 } else {
-- 
2.4.9 (Apple Git-60)

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Fixing build when changing kernel PREFERRED_PROVIDER

[Bryan Evenson]

Andre,

> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: Wednesday, December 02, 2015 4:57 PM
> To: Bryan Evenson 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Fixing build when changing kernel
> PREFERRED_PROVIDER
> 
> On Wed, Dec 2, 2015 at 1:08 PM, Bryan Evenson
>  wrote:
> > I'm on poky/dizzy-1.7.2 and I'm in the process of updating to poky/dizzy-
> 1.7.3.  I'm using an Atmel processor, so while I'm at it I'm pulling in 
> changes
> from meta-atmel (over at https://github.com/linux4sam/meta-atmel, dizzy
> branch).  One of the commits I pulled in was this one:
> https://github.com/linux4sam/meta-
> atmel/commit/ae10c274a681adebb1b59ea1173e6a8c603b66f1.  This
> renamed the kernel package from linux-yocto-custom to linux-at91.  After
> this change when I tried to build the image, I was greeted with a very long 
> list
> of files and the following error:
> >
> > The build has stopped as continuing in this scenario WILL break
> > things, if not now, possibly in the future (we've seen builds fail several
> months later). If the system knew how to recover from this automatically it
> would however there are several different scenarios which can result in this
> and we don't know which one this is. It may be you have switched providers
> of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), 
> in
> that case you need to execute the clean task for both recipes and it will
> resolve this error. It may be you changed DISTRO_FEATURES from systemd
> to udev or vice versa. Cleaning those recipes should again resolve this error
> however switching DISTRO_FEATURES on an existing build directory is not
> supported, you should really clean out tmp and rebuild (reusing sstate should
> be safe). It could be the overlapping files detected are harmless in which
> case adding them to SSTATE_DUPWHITELIST may be the correct solution. It
> could also be your buil  d is including two different conflicting versions of
> things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to
> resolve the conflict. If in doubt, please ask on the mailing list, sharing the
> error and filelist above.
> > ERROR: If the above message is too much, the simpler version is you're
> advised to wipe out tmp and rebuild (reusing sstate is fine). That will 
> likely fix
> things in most (but not all) cases.
> > ERROR: Function failed: sstate_task_postfunc
> >
> > I issued 'bitbake -c clean linux-at91' and then 'bitbake -c clean 
> > linux-yocto-
> custom'.  Linux-at91 cleaned without issue, but when I tried to clean linux-
> yocto-custom I got an error saying "Nothing PROVIDES 'linux-yocto-custom'".
> That in itself makes sense as there is no longer any recipe for linux-yocto-
> custom.  However, I'd like to avoid deleting the entire tmp directory.  I 
> don't
> have the speediest machine and I'd like to avoid wasting a day if there was a
> simpler solution.
> >
> > Is there a less destructive fix to this problem than deleting the tmp
> directory, or is that the only safe way to fix this problem?
> 
> If you can restore the old linux-yocto-custom recipe (e.g. temporarily git
> revert the commit that removed it) then you should be able to run it's clean
> task.
> 
> Deleting tmp is probably safer and quicker though. It certainly should not
> take a day to recreate it if you keep your downloads and sstate directories
> intact.

I had no idea how much is stored in the sstate.  I thought if I deleted the tmp 
directory it would have to rebuild everything instead of just populate the 
sysroot and repackage.  The rebuild of tmp and image build only took about 45 
minutes; much better than I expected.

Thanks,
Bryan

> 
> > Thanks,
> > Bryan
> > --
> > ___
> > 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] Pure initramfs image

[Michael Habibi]

All,

I have interest in creating an image that runs purely in an initramfs
space. It seems that overall this shouldn't be too difficult - I can set my
IMAGE_FSTYPE to cpio.gz, and as long as it's a reasonable size, it
shouldn't be an issue to point to it as an initrd. The only quirk is that
kernel modules are split out from the rootfs deployment (two separate
archives). Is there a way to combine the modules directly into the rootfs
archive?

Thanks,
Michael
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Pure initramfs image

[Gary Thomas]

On 2015-12-03 09:24, Michael Habibi wrote:

All,

I have interest in creating an image that runs purely in an initramfs space. It 
seems that overall this shouldn't be too difficult - I can set my IMAGE_FSTYPE 
to cpio.gz, and as
long as it's a reasonable size, it shouldn't be an issue to point to it as an 
initrd. The only quirk is that kernel modules are split out from the rootfs 
deployment (two separate
archives). Is there a way to combine the modules directly into the rootfs 
archive?


Just add the kernel-modules package to your install.  This
will install all of the kernel modules into your rootfs.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Big Endian set for qemuarm64 build based on poky

[akuster808]

Jin Li,

On 12/02/2015 09:53 PM, Jin Li wrote:
> Hi,
> 
> There is build error when I'm trying to build qemuarm64 project based on 
> default poky git repo with the big endian set as follows:
> 
> l00356543@hulk-test1:~/poky$ git diff 
> meta/conf/machine/include/arm/arch-arm64.inc
> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc 
> b/meta/conf/machine/include/arm/arch-arm64.inc
> index 866b71f..8fe6660 100644
> --- a/meta/conf/machine/include/arm/arch-arm64.inc
> +++ b/meta/conf/machine/include/arm/arch-arm64.inc
> @@ -1,4 +1,4 @@
> -DEFAULTTUNE ?= "aarch64"
> +DEFAULTTUNE ?= "aarch64_be"
> 
>  require conf/machine/include/arm/arch-armv7a.inc
> 
> l00356543@hulk-test1:~/poky$
> 
> 
> 
> Attach the build log:
> 
> l00356543@hulk-test1:~/qemuarm64_be$ bitbake core-image-sato
> Parsing recipes: 100% 
> |###|
>  ETA:  00:00:00
> Parsing of 888 .bb files complete (0 cached, 888 parsed). 1310 targets, 61 
> skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> 
> Build Configuration:
> BB_VERSION= "1.28.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-14.04"
> TARGET_SYS= "aarch64_be-poky-linux"
> MACHINE   = "qemuarm64"
> DISTRO= "poky"
> DISTRO_VERSION= "2.0"
> TUNE_FEATURES = "aarch64 bigendian"
> TARGET_FPU= ""
> meta
> meta-yocto
> meta-yocto-bsp= "master:698c74c373110ed081a7586e21d4a27b8b44c89b"
> 
> NOTE: Preparing RunQueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> WARNING: Failed to fetch URL 
> http://downloads.sourceforge.net/libusb/libusb-1.0.20.tar.bz2, attempting 
> MIRRORS if available
> WARNING: Failed to fetch URL 
> http://bitmath.org/code/mtdev/mtdev-1.1.5.tar.bz2, attempting MIRRORS if 
> available
> WARNING: Failed to fetch URL 
> http://wiki.qemu-project.org/download/qemu-2.4.0.1.tar.bz2, attempting 
> MIRRORS if available
> ERROR: oe_runmake failed
> ERROR: Function failed: do_compile (log file is located at 
> /home/l00356543/qemuarm64_be/tmp/work/qemuarm64-poky-linux/linux-yocto/4.1.13+gitAUTOINC+30c4b4bd79_c22dc676d6-r0/temp/log.do_compile.43788)
> ERROR: Logfile of failure stored in: 
> /home/l00356543/qemuarm64_be/tmp/work/qemuarm64-poky-linux/linux-yocto/4.1.13+gitAUTOINC+30c4b4bd79_c22dc676d6-r0/temp/log.do_compile.43788
> 
> ...
> 
> |   LD  arch/arm64/kernel/vdso/built-in.o
> | aarch64_be-poky-linux-ld.bfd: usr/initramfs_data.o: compiled for a little 
> endian system and target is big endian
> | aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file 
> usr/initramfs_data.o
> | make[3]: *** [usr/built-in.o] Error 1

This looks like the kernel config is set to 'LE'. Please try bitbake -c
menuconfig yocto-linux and change to 'BE"

- armin
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] YOCTO: Device Tree Issue - Linux Kernel Does Not Boot

[Paul DeMetrotion]

I am brand new to Yocto and have an issue that I cannot resolve. I have 
searched through the existing documentation and archives without any luck.

We have a custom SBC based on the Freescale i.MX6Q processor that previously 
used LTIB to create a Linux BSP. I have been tasked with converting to Yocto 
and have used the existing Freescale Sabre-SD as my model. I created a conf 
file for our device and located it in 
build-c398/sources/meta-fsl-arm-extra/conf/machine. Its contents are:

#@TYPE: Machine
#@NAME: i.MX6Q SBC35-C398
#@SOC: i.MX6Q
#@DESCRIPTION: Machine configuration for i.MX6Q SBC35-C398
#@MAINTAINER: Paul DeMetrotion 
require conf/machine/include/imx-base.inc
require conf/machine/include/tune-cortexa9.inc
SOC_FAMILY = "mx6:mx6q"
KERNEL_DEVICETREE = "imx6q-c398.dtb"
UBOOT_CONFIG ??= "sd"
UBOOT_CONFIG[sd] = "mx6qc398_config,sdcard"
UBOOT_CONFIG[sata] = "mx6qc398_sata_config"
UBOOT_CONFIG[mfgtool] = "mx6qc398_config"
SERIAL_CONSOLE = "115200 ttymxc0"

I have successfully built and booted u-boot and am now attempting to boot a 
core-image-base version of the Linux kernel. The system locks up after 
displaying 'Starting kernel ...'. I have tracked the problem to the function 
early_init_dt_scan(dt). The address being passed in the dt variable does not 
point to my device tree but instead points to a location that includes u-boot 
parameters. When the code checks for the 0xD00DFEED signature, the code fails 
and proceeds to the dump_machine_table infinite loop.

I created a device tree for our SBC and placed it in arch/arm/boot/dts. It 
appears to build properly and has the proper DTB signature in the first dword. 
The image copied to the SD card includes the DTB file in the same partition as 
the uImage.

Any idea why my code does not point to my DTB data? Am I missing something in 
my recipe or configuration files?

I hope I have explained my problem adequately. Thanks in advance for any help.

Paul DeMetrotion
Software Guru
WinSystems, Inc.
(972) 571-8657
www.winsystems.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Pure initramfs image

[Michael Habibi]

Oh well that's easy. I figured it was already added because it was in the
deployed directory, but I guess the tasks behave differently.

On Thu, Dec 3, 2015 at 10:32 AM, Gary Thomas  wrote:

> On 2015-12-03 09:24, Michael Habibi wrote:
>
>> All,
>>
>> I have interest in creating an image that runs purely in an initramfs
>> space. It seems that overall this shouldn't be too difficult - I can set my
>> IMAGE_FSTYPE to cpio.gz, and as
>> long as it's a reasonable size, it shouldn't be an issue to point to it
>> as an initrd. The only quirk is that kernel modules are split out from the
>> rootfs deployment (two separate
>> archives). Is there a way to combine the modules directly into the rootfs
>> archive?
>>
>
> Just add the kernel-modules package to your install.  This
> will install all of the kernel modules into your rootfs.
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> 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] Build from local mirror GCC recipe

[Ilya Katsnelson]

I'm trying to figure out how to convince Yocto to build gcc using my local GIT 
source rather than standard location it uses. So by default the recipe to build 
GCC located in meta/recipes-devtools/gcc/gcc-5.2.inc points to
BASEURI = "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
as the location of the code. I don't want to change the released Yocto code and 
thus created my own meta layer. However, how to change that BASEURI location in 
my layer? Should I create the same meta/recipes-devtools/gcc/gcc-5.2.inc recipe 
for GCC in my layer? The bitbake will use that recipe (I hope) since my layer 
has higher priority. Or I can use the gcc_5.2.bbappend in my layer and change 
source location there?
Thanks so much,
-Ilya.

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Best practice for files copied directly into sysroot?

[Michael Habibi]

Bryan,

I looked through the documentation and I'm a bit unclear on how to use
bin_package, and haven't been able to find a good example. Where do I
actually place my rootfs files/binaries to get copied to my image rootfs?
Under ${THISDIR}/${PN} like other recipe artifacts? How does it copy them
to ${S}? Or is this something I need to do?

Thanks,
Michael

On Tue, Dec 1, 2015 at 2:03 PM, Michael Habibi  wrote:

> Thanks Bryan!
>
> On Tue, Dec 1, 2015 at 1:50 PM, Bryan Evenson 
> wrote:
>
>> Michael,
>>
>> > -Original Message-
>> > From: yocto-boun...@yoctoproject.org [mailto:yocto-
>> > boun...@yoctoproject.org] On Behalf Of Michael Habibi
>> > Sent: Tuesday, December 01, 2015 10:26 AM
>> > To: yocto@yoctoproject.org
>> > Subject: [yocto] Best practice for files copied directly into sysroot?
>> >
>> > I am working on potentially migrating our distribution to Yocto (will
>> be a long,
>> > long process). We have an area of our filesystem where any file placed
>> will go
>> > directly into the rootfs of the target. This works well with our
>> product, as we
>> > have certain binaries and scripts that need to be copied directly, and
>> there's
>> > no other real step involved (no compilation, etc). Is there a best
>> practice or
>> > existing class that handles this? I saw mention of a binary/ directory
>> but I
>> > wasn't sure if that was for this or something else.
>> >
>> > Thanks,
>> > Michael
>>
>> I'm glad I decided to answer your question because I think I found an
>> easier way to do it than I have been doing this in the past.  If you want
>> to be able to update the files on your system at a later date, you will
>> want to make your own recipe which installs the binaries and scripts onto
>> the rootfs.  In general you create a recipe which does not have
>> do_configure or do_compile tasks.  There is a class that does this already
>> called "bin_package" that does this for you.  See the "Packaging Externally
>> Produced Binaries" section of the manual here:
>> http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#new-recipe-testing-examples.
>>  So if you include the line "inherit bin_package" and follow the
>> instructions in that section of the manual, it should install all the files
>> to the rootfs that are included in the recipe.
>>
>> Regards,
>> Bryan
>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto