available in a few hours. Please begin testing
> as they are available.
>
> Location: http://autobuilder.yoctoproject.org/pub/nightly/20130611-2
>
> meta-fsl-armd31a4e85673874dbc6b42bb5d1e8496810c574cc
> meta-fsl-ppc51252492cdda18eb3838b1c3108217a59243ba2a
> meta-intel
Hi Gaurang,
On Jun 11, 2013, at 10:47 PM, Gaurang Shastri
mailto:gmshas...@gmail.com>> wrote:
Can you try with IMAGE_INSTALL_append = " e2fsprogs" and run once again
"bitbake core-image-minimal" or whatever you are referring for your final target
The 'e2fsprogs' target adds libs, but not the e
Paul,
Thanks for pointing out these areas where it is confusing. Maybe someone on
the team can add some comments about the gcc-* recipe stuff. I don't have that
understanding but if I am giving more explanation I can update that entry. I
believe the term Cross-Development Toolchain" is the s
Can you try with IMAGE_INSTALL_append = " e2fsprogs" and run once again
"bitbake core-image-minimal" or whatever you are referring for your final
target
//Gaurang Shastri
On Wed, Jun 12, 2013 at 1:06 AM, Ben Warren wrote:
> Sorry for the spam. Still learning how this works…
>
> Turns out I nee
Attendees:
Andrei, Darren, Cristian, Foo Chien, ScottR, Richard, TomZ, KevinS, DaveST,
Jessica, Ross, Belen, Paul, LaurentiuP, Corneliu, Nitin, BruceA, SongL
Agenda:
* Opens collection - 5 min (Song)
* Yocto 1.4.1 status (Paul)
. RC1 build is done last night. One failure, parallel build/instal
Hi Jessica,
By the sentence "No crosscompiler for my target installed in my toolchain",
I mean I don't find the binaries for crosscompiling which are usually
present in the directory as shown below
*damarla@linuxbuildsrv:~/yocto/myToolchain/sysroots/x86_64-pokysdk-linux/usr/bin$
ls*
*aclocal
I'm trying a second time to see if I can learn this system. Section 3.4
contains a short glossary which explains some things and seems to obscure
others. So perhaps someone can clear up a few simple things.
"Cross-Development Toolchain: A collection of software development tools and
utilities that
a few hours. Please begin testing
as they are available.
Location: http://autobuilder.yoctoproject.org/pub/nightly/20130611-2
meta-fsl-armd31a4e85673874dbc6b42bb5d1e8496810c574cc
meta-fsl-ppc51252492cdda18eb3838b1c3108217a59243ba2a
meta-intel 048def7bae8e3e1a11c91f5071f99bdcf8e6dd16
Hi Diego,
On Tuesday 11 June 2013 14:28:09 Diego wrote:
> I have written a recipe which I'd like to contribute for glmark2:
> https://launchpad.net/glmark2
>
> The last thing that puzzles me before submitting it is that it's partly
> GPL3+, and partly under this license:
> https://github.com/rafa
On Tue, Jun 11, 2013 at 5:28 AM, Diego wrote:
> Hi everybody,
>
> I have written a recipe which I'd like to contribute for glmark2:
> https://launchpad.net/glmark2
>
> The last thing that puzzles me before submitting it is that it's partly GPL3+,
> and partly under this license:
> https://github.c
Sorry for the spam. Still learning how this works…
Turns out I needed 'e2fsprogs-mke2fs'
regards,
Ben
On Jun 11, 2013, at 10:51 AM, Ben Warren wrote:
> Hi,
>
> I'm trying to get the 'mkfs.ext4' binary from e2fsprogs into my image, in
> particular the '.ext3' rootfs image, and am obviously m
Hi Satya,
What is your cross compiler that you said it's not installed? For example, on
my development host e.g. x86, after I install the toolchain, there's an
environment-setup-*** file, inside it specifies what is your cross compiler,
e.g. arm-poky-linux-gnueabi-gcc for my case, after I sou
First I am sorry about the Gentlemen Next time it would be Ladies &
Gentlemen... ;-)
Let me explain the situation better ... *core-image-skidata* (arm) is
customized image which I build and I want to build a toolchain for this
image on my x86_64 with should consist of cross compiler (which I a
Hi,
I'm trying to get the 'mkfs.ext4' binary from e2fsprogs into my image, in
particular the '.ext3' rootfs image, and am obviously missing something
fundamental.
I'm using a custom image based on (copy/pasted from) 'kvm_image_minimal', and
have added 'e2fsprogs' to the IMAGE_INSTALL string in
On Tue, Jun 11, 2013 at 5:59 AM, DAMARLA Satya Swaroop
wrote:
> Gentlemen! We have a problem here...
Not all here are gentlemen :)
> I compiled the toolchain using the command bitbake core-image-skidata -c
> populate_sdk and installed the toolchain but I have to tell you that I dont
> see any cr
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
On Tuesday 11 June 2013 16:47:53 Javi Roman wrote:
> With
>
> SRC_URI_append = "file://defconfig"
Does your actual recipe have a leading space in the value? _append won't add
this for you so you have to do it explicitly.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
_
From: Muhammad Shakeel
Portmap systemd service is expecting this file to be present and
without this patch portmap service will fail, with timeout status.
Signed-off-by: Muhammad Shakeel
---
.../portmap/portmap/pid_file_creation.patch| 162
recipes-connectivity/po
From: Muhammad Shakeel
-l prevents portmap from binding to other external networking
interfaces i.e. ethernet
Signed-off-by: Muhammad Shakeel
---
.../portmap/portmap/portmap.service|2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-connectivity/portm
From: Muhammad Shakeel
portmap is a resident program and we want to start it in background.
With service type 'forking' systemd knows that the executable is a daemon.
Although in this case 'oneshot' + 'RemainAfterExit=yes' works but it
is intended for non-resident programs.
Signed-off-by: Muhamm
On 13-06-11 10:47 AM, Javi Roman wrote:
With
SRC_URI_append = "file://defconfig"
Which is what I expected. And you say that it isn't being applied
at all ? Is that by inspecting the final contents of .config ?
Or something else ?
Since this is on the dylan branches, I know it has been tested
Hello all
I am trying to understand the various branches of poky.
It appears that 1.4_M6 became dylan-9.0.0 which is DISTRO_VERSION=
"1.4". Is this correct?
top level of meta-oe
git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/danny
remotes/origin/danny-next
With
SRC_URI_append = "file://defconfig"
Javi Roman
On Tue, Jun 11, 2013 at 4:23 PM, Bruce Ashfield
wrote:
> On 13-06-11 10:18 AM, Javi Roman wrote:
>>
>> Hi!
>>
>>
>> I few years ago I used to work with OpenEmbedded (the classical
>> branch). The addition of new kernel recipes was easy for m
On 13-06-11 10:18 AM, Javi Roman wrote:
Hi!
I few years ago I used to work with OpenEmbedded (the classical
branch). The addition of new kernel recipes was easy for me,
nevertheless I'm unable to do similar things with the current
Yocto-dylan branch.
The current Yocto-dylan is based on Linux k
Hi!
I few years ago I used to work with OpenEmbedded (the classical
branch). The addition of new kernel recipes was easy for me,
nevertheless I'm unable to do similar things with the current
Yocto-dylan branch.
The current Yocto-dylan is based on Linux kernel 3.x branches, all the
documentation
- when ok is pressed, the system tap window is resized in stead of running the
script
- this is caused by the fact that the window is opened twice and only the
second call is taken into consideration
[Yocto #4598]
Signed-off-by: Ioana Grigoropol
---
.../sdk/remotetools/actions/SystemtapHandler
Gentlemen! We have a problem here...
I compiled the toolchain using the command *bitbake core-image-skidata -c
populate_sdk *and installed the toolchain but I have to tell you that I
dont see any cross-compiler installed with the toolchain...
Any guesses what could be the reason.. The image is cu
From: Noor
* The newly included patch, systemd_service_installation.patch, is required
because the cmake script in the dlt-daemon package tries to locate the
systemd units directory on the host. During cross compiling it should not
see paths on local machine and make decesion based on it. O
Hi everybody,
I have written a recipe which I'd like to contribute for glmark2:
https://launchpad.net/glmark2
The last thing that puzzles me before submitting it is that it's partly GPL3+,
and partly under this license:
https://github.com/rafalmiel/glmark2-wl/blob/master/COPYING.SGI
which is not
Hello,
I just send a patch to the same list.
Noor
-Original Message-
From: Behrens, Holger [mailto:holger.behr...@windriver.com]
Sent: Tuesday, June 11, 2013 5:10 PM
To: Ahsan, Noor
Cc: yocto@yoctoproject.org; Sarbu, Florin-Ionut (Florin);
genivi-diagnostic-log-and-tr...@lists.genivi.o
Hi,
> From: Noor
Did you file a bug with upstream
http://projects.genivi.org/diagnostic-log-trace/ and provided them with these
patches too? As I do not see them on the email distribution list. If so, can
you make a reference to the bugzilla id(s) of any bug(s) you filed against the
DLT d
From: Noor
* The newly included patch, systemd_service_installation.patch, is required
because the cmake script in the dlt-daemon package tries to locate the
systemd units directory on the host. During cross compiling it should not
see paths on local machine and make decesion based on it. O
Hi Jessica,
The first fixme message is just a left-over. We don't need to perform any
waiting actions since the command is ran synchronously.
As for the second fixme, its purpose was to perform some clean-up of the
environment file (bitbake.env), and thus will be replaced with a call to "rm
-rf
This is only the cover letter for the entire patch series.
Changed since v1: - implemented FIXME tasks in BBSession.
The following changes since commit 57c5d62fab9bc1024a3cf1f3f840f7f3bcfd3167:
Fix Thread Access exception for systemtap Dialogs (2013-05-31 15:07:01 +0300)
are available in the
On 7 June 2013 11:45, Luo Zhenhua-B19537 wrote:
> [Luo Zhenhua-B19537] Does it make sense to log defects in YP bugzilla if
> issue is found on host with those CPU types?
We don't claim to only support x86 hosts, so yes.
> BTW, is there a limitation for maximum parallel number of Yocto build? I
On Tue, Jun 11, 2013 at 10:26:47AM +0100, Gary Thomas wrote:
> On 2013-06-11 10:07, Martin Jansa wrote:
> > On Tue, Jun 11, 2013 at 09:20:05AM +0100, Paul Eggleton wrote:
> >> On Monday 10 June 2013 20:16:22 Khem Raj wrote:
> >>> On Fri, Jun 7, 2013 at 4:11 AM, Gary Thomas wrote:
> Looks inte
On 2013-06-11 10:07, Martin Jansa wrote:
On Tue, Jun 11, 2013 at 09:20:05AM +0100, Paul Eggleton wrote:
On Monday 10 June 2013 20:16:22 Khem Raj wrote:
On Fri, Jun 7, 2013 at 4:11 AM, Gary Thomas wrote:
Looks interesting and I think I'd like to try it myself. However, that
page has a referen
On Tue, Jun 11, 2013 at 09:20:05AM +0100, Paul Eggleton wrote:
> On Monday 10 June 2013 20:16:22 Khem Raj wrote:
> > On Fri, Jun 7, 2013 at 4:11 AM, Gary Thomas wrote:
> > > Looks interesting and I think I'd like to try it myself. However, that
> > > page has a reference to
> > > http://bugs.open
On Monday 10 June 2013 20:16:22 Khem Raj wrote:
> On Fri, Jun 7, 2013 at 4:11 AM, Gary Thomas wrote:
> > Looks interesting and I think I'd like to try it myself. However, that
> > page has a reference to
> > http://bugs.openembedded.org/attachment.cgi?id=1032&action=view
> > which seems to be dow
This mail was sent out by Package Report System.
It will list all the recipes which can't check upstream version by script, and
will show how long it is since their last mannual version check.
You can check the detail information at
http://packages.yoctoproject.org/manuallychkinfo
PackageName
This mail was sent out by Package Report System.
This message list those recipes which need to be upgraded. If maintainers
believe some of them needn't to upgrade this time, they can fill in
RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this
recipe remainder until newer u
41 matches
Mail list logo
