Re: [yocto] yocto query on SR_URI creation
On Monday 16 September 2013 23:16:51 Khem Raj wrote: > On Sep 16, 2013, at 10:54 PM, Rohit2 Jindal > wrote: > > Please suggest me the way to git clone from two repos parallel in the same > > recipe Is possible in yocto .If yes how to do that. Eg > > SRC_URI = > > "git://ep-code.xyz.com/sysconfig.git;branch=xxx-ep-20130823-3.0-alpha;pro > > tocol=ssh SRC_URI = > > "git://ep-code.xyz.com/xload.git;branch=xxx-ep-20130823-3.0-alpha;protoco > > l=ssh When I tries to do this it unpacks the source downloaded to > > WORKDIR/git so overwrites the first unpack with the other. So please > > suggest me the way that two download two repos in same recipes with their > > detstined cloned folder changed to folder with my required naming > > convention instead of generic git name folder in workdir. > > you could try using 'subpath' param to git fetcher. > > try something like > > SRC_URI = > "git://ep-code.xyz.com/sysconfig.git;branch=xxx-ep-20130823-3.0-alpha;proto > col=ssh;subpath=git1" SRC_URI = > "git://ep-code.xyz.com/xload.git;branch=xxx-ep-20130823-3.0-alpha;protocol= > ssh;subpath=git2" > > and see if that helps "subpath" isn't the right thing here; that will also copy only a subdirectory out of the git repository instead of the root. "destsuffix" is what you should set if you want to use something other than "git" Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto query on SR_URI creation
On Tuesday 17 September 2013 14:28:36 Rohit2 Jindal wrote: > The way you mentioned to put option inSRC_URI doesnot work it allows to > download first repository in SRC_URI and gives error not allowing to > download Second one. Gives error branch checkout id is not a valid id for > second src_uri. > > Please suggest me the alternative to handle the same. Could you please show the SRC_URI lines you are using now? Thanks, Paul PS Please also keep the discussion on the mailing list, thanks. -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] DISTRO_FEATURES_append, anyway to override?
We are using a user defined distro, based on poky-tiny. That is, we 'require' poky-tiny.conf. It is done this way in order not clutter our distro configuration with too much magics and defaults. However, one problem now is that poky-tiny also 'require' poky.conf, and implicitly is doing DISTRO_FEATURES_append = " largefile opengl multiarch wayland" In our configuration we do DISTRO_FEATURES_append = "nfs" The resulting DISTRO_FEATURES (as checked by bitbake -e) shows that everything appended by poky is also added to the custom distro. Now, we would like to remove everything but the large file support as added by poky. How do we do that? Is the only practical way to copy everything from poky.conf and poky-tiny.conf into the custom distro? I really would like to avoid that if possible. I guess that the new feature DISTRO_FEATURES_remove might help us here, but unfortunately we can no step up to such a late version in a foreseeable future. Thanks. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto query on SR_URI creation
Hi, SRC_URI = "git://ep-code.xtz.com/u-boot.git;branch=xxx-ep-20130823-3.0-alpha;protocol=ssh;subpath=uboot" SRC_URI = "git://ep-code.xtz.com/x-load.git;branch=xxx-ep-20130823-3.0-alpha;protocol=ssh;subpath=xload" Regards, Rohit Jindal -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: Tuesday, September 17, 2013 2:32 PM To: Rohit2 Jindal Cc: yocto@yoctoproject.org Subject: Re: [yocto] yocto query on SR_URI creation On Tuesday 17 September 2013 14:28:36 Rohit2 Jindal wrote: > The way you mentioned to put option inSRC_URI doesnot work it allows > to download first repository in SRC_URI and gives error not allowing > to download Second one. Gives error branch checkout id is not a valid > id for second src_uri. > > Please suggest me the alternative to handle the same. Could you please show the SRC_URI lines you are using now? Thanks, Paul PS Please also keep the discussion on the mailing list, thanks. -- Paul Eggleton Intel Open Source Technology Centre === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. === ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto query on SR_URI creation
On Tuesday 17 September 2013 14:35:53 Rohit2 Jindal wrote:
> SRC_URI =
> "git://ep-code.xtz.com/u-boot.git;branch=xxx-ep-20130823-3.0-alpha;protocol
> =ssh;subpath=uboot" SRC_URI =
> "git://ep-code.xtz.com/x-load.git;branch=xxx-ep-20130823-3.0-alpha;protocol
> =ssh;subpath=xload"
There are several problems with the above:
1) In my reply I mentioned that subpath is not the right option to use. Use
destsuffix instead.
2) You can't just do SRC_URI = twice, the second time it will just overwrite
the value from the first statement.
3) You'll need to specify name= for each item and then specify SRCREV for each
one ("${AUTOREV}" if you want to use the latest on the specified branch).
So you'll need something like:
SRC_URI =
"git://ep-code.xtz.com/u-boot.git;branch=xxx-ep-20130823-3.0-alpha;protocol=ssh;name=uboot;destsuffix=git/uboot
\
git://ep-code.xtz.com/x-load.git;branch=xxx-ep-20130823-3.0-alpha;protocol=ssh;name=xload;destsuffix=git/xload"
SRCREV_uboot = "${AUTOREV}"
SRCREV_xload = "${AUTOREV}"
Don't forget also to set S = "${WORKDIR}/git" as well.
Note that if you want to use ${SRCPV} in PV to get the source revision in
the version, you'll also need to set SRCREV_FORMAT to tell the system
how to compose SRCPV from the two SRCREV values e.g.
SRCREV_FORMAT = "uboot_xload"
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Media players: recipes and packages
Hello Task #9 - How to add bad/ugly: https://community.freescale.com/docs/DOC-95254 Thanks Daiane, jose PD: search keywords: yocto gstreamer bad ugly El 16/09/2013 18:14, Jose Mª Ferreiro escribió: Hello Here is: iMX6 Sabre Lite + Yocto dylan We want to reproduce some music and video files to test the board behaviour. With fsl-image-gui: - Video player: a mp4 file is well reproduced. Image is good. Sound is low but I can hear it with headphones connected to board. - Music player: when we select a mp3 file, the window closes With core-image-sato-sdk: - Video player: when we select a mp4 file, an error comes: a plug-in is needed - Music player: when we select a mp3 file, the player shows it, but the play does not start How can I find what package/recipe in fsl-image-gui does mp4 work? Is there any way to know what kind of files can play each image by default? Thanks, Jose ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] DISTRO_FEATURES_append, anyway to override?
On Tue, Sep 17, 2013 at 11:04 AM, Hans Beckérus wrote: > We are using a user defined distro, based on poky-tiny. That is, we > 'require' poky-tiny.conf. > It is done this way in order not clutter our distro configuration with > too much magics and defaults. > However, one problem now is that poky-tiny also 'require' poky.conf, > and implicitly is doing > > DISTRO_FEATURES_append = " largefile opengl multiarch wayland" > > In our configuration we do > > DISTRO_FEATURES_append = "nfs" > > The resulting DISTRO_FEATURES (as checked by bitbake -e) shows that > everything appended by poky is also added to the custom distro. > Now, we would like to remove everything but the large file support as > added by poky. How do we do that? Is the only practical way to copy > everything from poky.conf and poky-tiny.conf into the custom distro? I > really would like to avoid that if possible. > I guess that the new feature DISTRO_FEATURES_remove might help us > here, but unfortunately we can no step up to such a late version in > a foreseeable future. > Maybe this is the patch we need, it seems to adress exactly this problem. http://www.mail-archive.com/yocto@yoctoproject.org/msg14784.html > Thanks. > Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] DISTRO_FEATURES_append, anyway to override?
On Tue, Sep 17, 2013 at 12:15 PM, Hans Beckérus wrote: > > The resulting DISTRO_FEATURES (as checked by bitbake -e) shows that > > everything appended by poky is also added to the custom distro. > > Now, we would like to remove everything but the large file support as > > added by poky. How do we do that? Is the only practical way to copy > > everything from poky.conf and poky-tiny.conf into the custom distro? I > > really would like to avoid that if possible. > > I guess that the new feature DISTRO_FEATURES_remove might help us > > here, but unfortunately we can no step up to such a late version in > > a foreseeable future. > > > Maybe this is the patch we need, it seems to adress exactly this problem. > http://www.mail-archive.com/yocto@yoctoproject.org/msg14784.html > i agree with this conclusion. this has been 'fixed' in master, but needs to be backported to dylan (and danny), i believe. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel debugging over serial console?
I am trying to debug the kernel through kgdb for an imx6 sabre lite board with
the following kernel built from poky 1.4:
root@imx6qsabrelite:~# uname -a
Linux imx6qsabrelite 3.0.35-1.1.0+g2dc5560 #1 SMP PREEMPT Thu Aug 8 15:15:39
CEST 2013 armv7l GNU/Linux
The system boot well but when I try to enter in debugging mode it returns:
root@imx6qsabrelite:~# echo g > /proc/sysrq-trigger
SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E)
memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK
show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N)
powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T)
Unmount ETM buffer dump show-blocked-tasks(W)
root@imx6qsabrelite:~#
I have configured the kernel with the command:
bitbake -c menuconfig linux-imx
enabling:
-*- Magic SysRq key
[*] Kernel debugging
[*] Compile the kernel with debug info
[*] KGDB: kernel debugger
<*> KGDB: use kgdb over the serial console
I have also edited defconfig file in
fsl-community-bsp-dylan/sources/meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6q/
adding:
CONFIG_FRAME_POINTER=y
CONFIG_DEBUG_KERNEL=y
CONFIG_KGDB=y
CONFIG_DEBUG_INFO=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_MAGIC_SYSRQ=y
and added kernel parameter to bootargs with:
MX6QSABRELITE U-Boot > editenv mmcargs
edit: setenv bootargs console=${console},${baudrate} root=${mmcroot}
kgdboc=ttymxc1,115200
MX6QSABRELITE U-Boot > saveenv
Saving Environment to MMC...
Writing to MMC(0)... done
MX6QSABRELITE U-Boot > boot
but it still does not work.
Thank You.
Giuseppe
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to reduce deploy/ipks only to what is contained on image?
All, I have an image that is based upon core-image-minimal (build poky/dylan-9.0.1) with a few extra packages. In total, 'opkg list-installed' on my target system shows about 100 packages installed. I am using the tmp/deploy/ipk directory as I have built as a basis for firmware upgrade for my devices, but there are many more packages in the ipk directories than my target system is using. The folder for my target architecture has around 3500 .ipk files, so there is a lot of clutter in the ipk directories. It'd be a lot more portable for firmware upgrade if I could reduce the contents of the ipk directory (and the resulting Packages and Packages.gz files) only contain the packages my system needs. What is the easiest way to recreate the tmp/deploy/ipk directories to only contain the packages that are needed by the built image and have the package index match those contents? Thanks, Bryan ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel debugging over serial console?
Hello Giuseppe,
On 17-Sep-13, BITONTI Giuseppe (MM) wrote:
> I am trying to debug the kernel through kgdb for an imx6 sabre lite board
> with the following kernel built from poky 1.4:
>
> root@imx6qsabrelite:~# uname -a
> Linux imx6qsabrelite 3.0.35-1.1.0+g2dc5560 #1 SMP PREEMPT Thu Aug 8 15:15:39
> CEST 2013 armv7l GNU/Linux
>
> The system boot well but when I try to enter in debugging mode it returns:
>
> root@imx6qsabrelite:~# echo g > /proc/sysrq-trigger
> SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E)
> memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK
> show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N)
> powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T)
> Unmount ETM buffer dump show-blocked-tasks(W)
> root@imx6qsabrelite:~#
I didn't dabble with OE or Yocto for a while, but from a pure Linux
kernel point of view, it seems like something is amiss with your kgdb
configuration.
> I have configured the kernel with the command:
>
> bitbake -c menuconfig linux-imx
>
> enabling:
>
> -*- Magic SysRq key
> [*] Kernel debugging
> [*] Compile the kernel with debug info
> [*] KGDB: kernel debugger
> <*> KGDB: use kgdb over the serial console
>
> I have also edited defconfig file in
> fsl-community-bsp-dylan/sources/meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6q/
> adding:
>
> CONFIG_FRAME_POINTER=y
> CONFIG_DEBUG_KERNEL=y
> CONFIG_KGDB=y
> CONFIG_DEBUG_INFO=y
> CONFIG_KGDB_SERIAL_CONSOLE=y
> CONFIG_MAGIC_SYSRQ=y
>
> and added kernel parameter to bootargs with:
>
> MX6QSABRELITE U-Boot > editenv mmcargs
> edit: setenv bootargs console=${console},${baudrate} root=${mmcroot}
> kgdboc=ttymxc1,115200
> MX6QSABRELITE U-Boot > saveenv
> Saving Environment to MMC...
> Writing to MMC(0)... done
> MX6QSABRELITE U-Boot > boot
You kernel configuration looks ok, and the kgdboc parameter passed by
u-boot to the kernel seems correct (at least syntactically speaking).
> but it still does not work.
Depending on the serial driver in use in the kernel, it sometimes
happens that kgdboc is not configured despite the kgdboc parameter
being passed to the kernel.
To check that kgdboc is configured like you intended, from user-sapce
please try:
root@imx6qsabrelite:~# cat /sys/module/kgdboc/parameters/kgdboc
Guessing from what you wrote, it should return: ttymxc1,115200
If it doesn't, please try configuring kgdboc from user-space:
root@imx6qsabrelite:~# echo ttymxc1,115200 >
/sys/module/kgdboc/parameters/kgdboc
And then:
root@imx6qsabrelite:~# echo g > /proc/sysrq-trigger
Should break the kernel and let you connect to kgdb using, for
instance, a gdb client.
Hope it helps :-).
Cheers.
--
Apelete
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] R: Kernel debugging over serial console?
Thanks Apelete for your help, but the command you suggested returns the
following:
root@imx6qsabrelite:~# cat /sys/module/kgdboc/parameters/kgdboc
cat: can't open '/sys/module/kgdboc/parameters/kgdboc': No such file or
directory
root@imx6qsabrelite:~# echo ttymxc1,115200 >
/sys/module/kgdboc/parameters/kgdboc
-sh: can't create /sys/module/kgdboc/parameters/kgdboc: nonexistent directory
What I miss?
Giuseppe
-Messaggio originale-
Da: Apelete Seketeli [mailto:apel...@seketeli.net]
Inviato: martedì 17 settembre 2013 15:15
A: BITONTI Giuseppe (MM)
Cc: yocto@yoctoproject.org
Oggetto: Re: [yocto] Kernel debugging over serial console?
Hello Giuseppe,
On 17-Sep-13, BITONTI Giuseppe (MM) wrote:
> I am trying to debug the kernel through kgdb for an imx6 sabre lite board
> with the following kernel built from poky 1.4:
>
> root@imx6qsabrelite:~# uname -a
> Linux imx6qsabrelite 3.0.35-1.1.0+g2dc5560 #1 SMP PREEMPT Thu Aug 8
> 15:15:39 CEST 2013 armv7l GNU/Linux
>
> The system boot well but when I try to enter in debugging mode it returns:
>
> root@imx6qsabrelite:~# echo g > /proc/sysrq-trigger SysRq : HELP :
> loglevel(0-9) reBoot Crash terminate-all-tasks(E)
> memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK
> show-backtrace-all-active-cpus(L) show-memory-usage(M)
> nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q)
> unRaw Sync show-task-states(T) Unmount ETM buffer dump
> show-blocked-tasks(W) root@imx6qsabrelite:~#
I didn't dabble with OE or Yocto for a while, but from a pure Linux kernel
point of view, it seems like something is amiss with your kgdb configuration.
> I have configured the kernel with the command:
>
> bitbake -c menuconfig linux-imx
>
> enabling:
>
> -*- Magic SysRq key
> [*] Kernel debugging
> [*] Compile the kernel with debug info [*] KGDB: kernel debugger <*>
> KGDB: use kgdb over the serial console
>
> I have also edited defconfig file in
> fsl-community-bsp-dylan/sources/meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6q/
> adding:
>
> CONFIG_FRAME_POINTER=y
> CONFIG_DEBUG_KERNEL=y
> CONFIG_KGDB=y
> CONFIG_DEBUG_INFO=y
> CONFIG_KGDB_SERIAL_CONSOLE=y
> CONFIG_MAGIC_SYSRQ=y
>
> and added kernel parameter to bootargs with:
>
> MX6QSABRELITE U-Boot > editenv mmcargs
> edit: setenv bootargs console=${console},${baudrate} root=${mmcroot}
> kgdboc=ttymxc1,115200 MX6QSABRELITE U-Boot > saveenv Saving
> Environment to MMC...
> Writing to MMC(0)... done
> MX6QSABRELITE U-Boot > boot
You kernel configuration looks ok, and the kgdboc parameter passed by u-boot to
the kernel seems correct (at least syntactically speaking).
> but it still does not work.
Depending on the serial driver in use in the kernel, it sometimes happens that
kgdboc is not configured despite the kgdboc parameter being passed to the
kernel.
To check that kgdboc is configured like you intended, from user-sapce please
try:
root@imx6qsabrelite:~# cat /sys/module/kgdboc/parameters/kgdboc
Guessing from what you wrote, it should return: ttymxc1,115200 If it doesn't,
please try configuring kgdboc from user-space:
root@imx6qsabrelite:~# echo ttymxc1,115200 >
/sys/module/kgdboc/parameters/kgdboc
And then:
root@imx6qsabrelite:~# echo g > /proc/sysrq-trigger
Should break the kernel and let you connect to kgdb using, for instance, a gdb
client.
Hope it helps :-).
Cheers.
--
Apelete
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel debugging over serial console?
On 17-Sep-13, Apelete Seketeli wrote:
> Hello Giuseppe,
>
> On 17-Sep-13, BITONTI Giuseppe (MM) wrote:
> > I have configured the kernel with the command:
> >
> > bitbake -c menuconfig linux-imx
> >
> > enabling:
> >
> > -*- Magic SysRq key
> > [*] Kernel debugging
> > [*] Compile the kernel with debug info
> > [*] KGDB: kernel debugger
> > <*> KGDB: use kgdb over the serial console
> >
> > I have also edited defconfig file in
> > fsl-community-bsp-dylan/sources/meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6q/
> > adding:
> >
> > CONFIG_FRAME_POINTER=y
> > CONFIG_DEBUG_KERNEL=y
> > CONFIG_KGDB=y
> > CONFIG_DEBUG_INFO=y
> > CONFIG_KGDB_SERIAL_CONSOLE=y
> > CONFIG_MAGIC_SYSRQ=y
> >
> > and added kernel parameter to bootargs with:
> >
> > MX6QSABRELITE U-Boot > editenv mmcargs
> > edit: setenv bootargs console=${console},${baudrate} root=${mmcroot}
> > kgdboc=ttymxc1,115200
> > MX6QSABRELITE U-Boot > saveenv
> > Saving Environment to MMC...
> > Writing to MMC(0)... done
> > MX6QSABRELITE U-Boot > boot
>
> You kernel configuration looks ok, and the kgdboc parameter passed by
> u-boot to the kernel seems correct (at least syntactically speaking).
I forgot to mention it, but you might want to add
"CONFIG_CONSOLE_POLL=y" to you kernel configuration to enable the
polling scheme used by the serial driver when working with kgdboc.
Cheers.
--
Apelete
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] R: Kernel debugging over serial console?
On 17-Sep-13, BITONTI Giuseppe (MM) wrote: > Thanks Apelete for your help, but the command you suggested returns the > following: > > root@imx6qsabrelite:~# cat /sys/module/kgdboc/parameters/kgdboc > cat: can't open '/sys/module/kgdboc/parameters/kgdboc': No such file or > directory > > root@imx6qsabrelite:~# echo ttymxc1,115200 > > /sys/module/kgdboc/parameters/kgdboc > -sh: can't create /sys/module/kgdboc/parameters/kgdboc: nonexistent directory > > What I miss? Interesting. I am not sure how it is handled in Poky 1.4, but on a vanilla Linux distribution you should have directories in /sys/module/ for the kernel modules which need them for their configuration. kgdboc being such a module, it should have its own directory there. Could you do: root@imx6qsabrelite:~# ls -l /sys/module/kgdboc And paste the output here ? Cheers. -- Apelete ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] R: R: Kernel debugging over serial console?
Thank you, I solved it. It was my mistake, I was modifing the wrong defconfig file. Regards, Giuseppe -Messaggio originale- Da: Apelete Seketeli [mailto:apel...@seketeli.net] Inviato: martedì 17 settembre 2013 16:12 A: BITONTI Giuseppe (MM) Cc: yocto@yoctoproject.org Oggetto: Re: R: [yocto] Kernel debugging over serial console? On 17-Sep-13, BITONTI Giuseppe (MM) wrote: > Thanks Apelete for your help, but the command you suggested returns the > following: > > root@imx6qsabrelite:~# cat /sys/module/kgdboc/parameters/kgdboc > cat: can't open '/sys/module/kgdboc/parameters/kgdboc': No such file > or directory > > root@imx6qsabrelite:~# echo ttymxc1,115200 > > /sys/module/kgdboc/parameters/kgdboc > -sh: can't create /sys/module/kgdboc/parameters/kgdboc: nonexistent > directory > > What I miss? Interesting. I am not sure how it is handled in Poky 1.4, but on a vanilla Linux distribution you should have directories in /sys/module/ for the kernel modules which need them for their configuration. kgdboc being such a module, it should have its own directory there. Could you do: root@imx6qsabrelite:~# ls -l /sys/module/kgdboc And paste the output here ? Cheers. -- Apelete ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problems building util-linux when wide character support is disabled in distro
Hi. We are having som problems building our rootfs now that our custom
distro (based on poky-tiny) no longer includes wide character support
in libc.
Here is an example of the errors we get:
| arm-poky-linux-gnueabi-libtool: link: arm-poky-linux-gnueabi-gcc
-march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mtune=cortex-a9
--sysroot=/home/qhanbec/poky/build/tmp/sysroots/zynq-zc706 -std=gnu99
-fsigned-char -fno-common -Wall -Werror=sequence-point -Wextra
-Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes
-Wno-missing-field-initializers -Wredundant-decls -Wsign-compare
-Wtype-limits -Wuninitialized -Wunused-but-set-parameter
-Wunused-but-set-variable -Wunused-parameter -Wunused-result
-Wunused-variable -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -o ul text-utils/ul.o -ltinfo
| text-utils/rev.o: In function `main':
|
/home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:139:
undefined reference to `fgetws'
|
/home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:151:
undefined reference to `fgetws'
|
/home//poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:154:
undefined reference to `wcslen'
|
/home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:160:
undefined reference to `putwchar'
|
/home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:162:
undefined reference to `putwchar'
| collect2: error: ld returned 1 exit status
The problem is that util-linux still thinks we have wide character
support (from configure.ac):
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
#include
#include
#include
]], [[
wchar_t wc;
wint_t w;
w = fgetwc(stdin);
if (w == WEOF) exit(1);
wc = w;
fputwc(wc,stdout);
]])],
[AC_DEFINE(HAVE_WIDECHAR,1,Do we have wide character support?)
])
Since no linking is performed due to x-compilation, all that this does
is basically checking if wchar.h exists or not.
And that is also were the problem is. Even if we have disabled wide
character support in eglibc, the wchar.h header files is still copied
to our sysroot!?
Is that really how it should be when DISTRO_FEATURES_LIBC does not
include 'libc-posix-clang-wchar libc-posix-wchar-io'?
Here is our DISTRO_FEATURES (as reported by bitbake -e) and build environment:
DISTRO_FEATURES="ipv4 usbhost usbgadget ${DISTRO_FEATURES_WIFI}
libc-libm libc-crypt libc-utmp libc-getlogin libc-posix-regexp
libc-inet libc-nis sysvinit largefile nfs"
Build Configuration:
BB_VERSION= "1.19.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "SUSE-LINUX-11"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE = "zynq-zc706"
DISTRO= "poky-chris"
DISTRO_VERSION= "1.4+snapshot-20130917"
TUNE_FEATURES = "armv7a vfp cortexa9"
TARGET_FPU= "vfp"
meta
meta-yocto
meta-yocto-bsp= "master:3b38c898a4647c6a639d0dbd416b0bbacbf278f5"
meta-oe = "master:7c292ce28756824b1fa377d516aedd979fa41f19"
Any ideas how what might be wrong here?
Thanks.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake on live (uncommitted) code
Hi Brad, On Tuesday 17 September 2013 17:48:18 Brad Litterell wrote: > I've been using externalsrc for a few days now and have a follow on > question. > > It appears that bitbake's state information for the various recipes doesn't > react to changes in source files in an external source. IOW, when I change > a file in my external folder I need to perform 3 steps to create a new file > system that reflects the change: > > bitbake -c clean > bitbake > bitbake > > Is it possible to ask bitbake to be more thorough about detecting file > changes in external sources and rebuild the affected component > automatically? I'm not sure if that would be practical; we'd need to checksum quite a lot of files for a large source tree. However, there is a slightly simpler method: bitbake -C compile bitbake Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake on live (uncommitted) code
Thank you! I've been using externalsrc for a few days now and have a follow on question. It appears that bitbake's state information for the various recipes doesn't react to changes in source files in an external source. IOW, when I change a file in my external folder I need to perform 3 steps to create a new file system that reflects the change: bitbake -c clean bitbake bitbake Is it possible to ask bitbake to be more thorough about detecting file changes in external sources and rebuild the affected component automatically? Thanks, Brad From: Paul Eggleton [paul.eggle...@linux.intel.com] Sent: Friday, September 13, 2013 2:55 AM To: Brad Litterell Cc: Chris Larson; yocto@yoctoproject.org Subject: Re: [yocto] Bitbake on live (uncommitted) code On Thursday 12 September 2013 17:23:53 Chris Larson wrote: > On Thu, Sep 12, 2013 at 4:53 PM, Brad Litterell wrote: > > I've grown to really appreciate bitbake for compiling code from a myriad > > of sources, however, what is the recommended course for source I am > > currently doing live development on? My code base lives in a couple of > > git > > repos that do NOT map one-to-one with recipes and I don't really want to > > store the source mixed in with the recipe meta data anyway, nor do I want > > to be forced to commit it to git just to do a build. > > > > Currently I run a pre-bitbake script that creates a tarball out of the > > > > source, but that is easy to forget and makes building a new image a two > > step proces. Since it is a build step I'd like it to be done by bitbake. > > > > Is there a recommended way to go about this? > > See externalsrc.bbclass. Also the manual section that talks about using it: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems building util-linux when wide character support is disabled in distro
On 2013-09-17 5:09, Hans Beckérus wrote:
> Hi. We are having som problems building our rootfs now that our custom
> distro (based on poky-tiny) no longer includes wide character support
> in libc.
> Here is an example of the errors we get:
>
> | arm-poky-linux-gnueabi-libtool: link: arm-poky-linux-gnueabi-gcc
> -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mtune=cortex-a9
> --sysroot=/home/qhanbec/poky/build/tmp/sysroots/zynq-zc706 -std=gnu99
> -fsigned-char -fno-common -Wall -Werror=sequence-point -Wextra
> -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes
> -Wno-missing-field-initializers -Wredundant-decls -Wsign-compare
> -Wtype-limits -Wuninitialized -Wunused-but-set-parameter
> -Wunused-but-set-variable -Wunused-parameter -Wunused-result
> -Wunused-variable -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1
> -Wl,--hash-style=gnu -Wl,--as-needed -o ul text-utils/ul.o -ltinfo
> | text-utils/rev.o: In function `main':
> |
> /home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:139:
> undefined reference to `fgetws'
> |
> /home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:151:
> undefined reference to `fgetws'
> |
> /home//poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:154:
> undefined reference to `wcslen'
> |
> /home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:160:
> undefined reference to `putwchar'
> |
> /home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:162:
> undefined reference to `putwchar'
> | collect2: error: ld returned 1 exit status
>
> The problem is that util-linux still thinks we have wide character
> support (from configure.ac):
>
> AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
> #include
> #include
> #include
> ]], [[
> wchar_t wc;
> wint_t w;
> w = fgetwc(stdin);
> if (w == WEOF) exit(1);
> wc = w;
> fputwc(wc,stdout);
> ]])],
> [AC_DEFINE(HAVE_WIDECHAR,1,Do we have wide character support?)
> ])
>
> Since no linking is performed due to x-compilation, all that this does
> is basically checking if wchar.h exists or not.
Actually, I think what is missing here is a AC_TRY_LINK.
But it does not seem to matter much. There are also numerous of places in the
util-linux code that are
completely missing out on checks if wide character support is available or not.
The way forward as I can see right now is to revert and put back the wide
character support in libc.
Unless I can figure out why util-linux is actually being built in the first
place? What can cause dependencies to this
package? It is not part of our IMAGE_FEATURES directly, nor indirectly and is
not installed in our rootfs.
But something requires it. Any hints on how to trace this back?
> And that is also were the problem is. Even if we have disabled wide
> character support in eglibc, the wchar.h header files is still copied
> to our sysroot!?
> Is that really how it should be when DISTRO_FEATURES_LIBC does not
> include 'libc-posix-clang-wchar libc-posix-wchar-io'?
> Here is our DISTRO_FEATURES (as reported by bitbake -e) and build environment:
>
> DISTRO_FEATURES="ipv4 usbhost usbgadget ${DISTRO_FEATURES_WIFI}
> libc-libm libc-crypt libc-utmp libc-getlogin libc-posix-regexp
> libc-inet libc-nis sysvinit largefile nfs"
>
> Build Configuration:
> BB_VERSION = "1.19.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING = "SUSE-LINUX-11"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE = "zynq-zc706"
> DISTRO= "poky-chris"
> DISTRO_VERSION= "1.4+snapshot-20130917"
> TUNE_FEATURES = "armv7a vfp cortexa9"
> TARGET_FPU= "vfp"
> meta
> meta-yocto
> meta-yocto-bsp= "master:3b38c898a4647c6a639d0dbd416b0bbacbf278f5"
> meta-oe = "master:7c292ce28756824b1fa377d516aedd979fa41f19"
>
> Any ideas how what might be wrong here?
>
> Thanks.
> Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] QMake & externalsrc incompatible?
I have a number of QT components that have qmake style .pro files.
In my recipe I inherit both externalsrc & qmake2. I'm using qmake2 based on
the quicky sample recipe since I don't need X11 or the other GUI libraries.
In the bitbake work folder, the generated run.do_configure script resembles
this:
cd /home/brad/ecom/build/toolchain/work/.../ecomapi-2.0-r0/ecomapi-2.0/
...
PROFILES="`ls *.pro`"
This is the location where a tarball would normally be unpacked, but in this
case I'm using externalsrc and the source files are not here. Therefore the ls
*.pro doesn't return anything for the automatic profile detection and the build
fails.
My recipe is very simple (removing the description & licensing):
PV = "2.0"
inherit externalsrc qmake2
S = "${OEBASE}/ecomapi"
OEBASE in this case is the /home/brad/ecom folder
I looked in the yocto bugzilla and didn't find a known issue for this. Am I
doing something wrong?
Thanks,
Brad
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] 1.5_M5.rc2 status
All, We attempted a spin of rc2 today and found issues that make it necessary for an rc3 spin which will probably happen tomorrow afternoon PST. We are going to let the build continue so that we can identify any other issues, but so far, the main issue seems to be libxml-parser-perl qa check complaining about a bad RPATH and poky-tiny deploy (which I have a fix I'm testing right now) -b -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux] Install policy headers and include them in the refpolicy dev package.
This patch is pretty straight forward: All we do is call the
'install-headers' make target at the end of do_install. We then add
the interface 'include' directory to the dev package. This allows
projects that ship their own SELinux policy (not in the refpolicy)
to build against the refpolicy headers / interface files by using
the Makefile supplied by refpolicy.
Signed-off-by: Philip Tricca
---
recipes-security/refpolicy/refpolicy_common.inc |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/recipes-security/refpolicy/refpolicy_common.inc
b/recipes-security/refpolicy/refpolicy_common.inc
index 2c8891a..0f9f83b 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -12,7 +12,8 @@ SRC_URI += "file://customizable_types \
S = "${WORKDIR}/refpolicy"
FILES_${PN} = "${sysconfdir}/selinux/${POLICY_NAME}/ \
- ${datadir}/selinux/${POLICY_NAME}/"
+ ${datadir}/selinux/${POLICY_NAME}/*.pp"
+FILES_${PN}-dev =+ "${datadir}/selinux/${POLICY_NAME}/include/"
DEPENDS += "checkpolicy-native policycoreutils-native m4-native"
RDEPENDS_${PN} += "policycoreutils selinux-config"
@@ -75,4 +76,7 @@ EOF
cat ${WORKDIR}/customizable_types >> \
${D}${sysconfdir}/selinux/${POLICY_NAME}/contexts/customizable_types
+
+ # install policy headers
+ oe_runmake install-headers DESTDIR=${D}
}
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
