[yocto] Yocto Virtual Keyboard in French

2016-05-23 Thread Chandrakanth Sherkhane (IC Nexus)
Dear Yocto mailing list,

 

The current information I know already is,

1.  Using a patch provided by a good friend of mine, the French Virtual
Keyboard can be built in Yocto and it is OK

2.  Now using a Touch screen with this French Virtual Keyboard is OK

3.  But using a Single Board Computer with Yocto, by connecting a
physical French USB Keyboard, it seems to follow the US layout, and not the
French layout

4.  This is due to the physical Keyboard is governed by the standard
Linux locales

 

Questions:

1.  How can I have a locale for French on my Yocto setup?

2.  How can I activate it by default?

 

Thanks in advance.

 

Best Regards,

Chandrakanth Sherkhane

c...@icnexus.com.tw

 

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


[yocto] Release Candidate Build for yocto-2.0.2.rc1.rc1 now available.

2016-05-23 Thread Poky Build User

A release candidate build for yocto-2.0.2.rc1 is now available at:


http://autobuilder.yoctoproject.org/pub/releases/yocto-2.0.2.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-qt4 : 4058b0773381f894d915ea3dfac5fe052d82a9a7 
meta-intel : 2397181e99d3155c7a00e1756cec92b568d9a9eb 
meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
meta-qt3 : b08996efbfb3b26e62b608f34ebf5e671b36ec61 
poky : dade0e68c645473d94e1b05020b064df40677e81 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flana...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] How can I set a recipe that its binaries become available at cross-compile time?

2016-05-23 Thread Mike Looijmans

On 23-05-16 15:37, s.jar...@esa-grimma.de wrote:

Hej

I a cmake based application, some code generation via dbusxx-xml2cpp. It is
provided by the dbuss-c++ lib. A recipe can be found under:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/meta-ivi-demo/recipes-extended/dbus-c++?id=b90c2a20744e1e82b2169a88e68d7677bec907b6


It working and it's compiling & linking, "dbusxx-xml2cpp" is included at the
native build.

How can I set a recipe that its binaries become available at cross-compile time?


Simply adding the following to a recipe should make the command available in 
the PATH:


DEPENDS += "dbus-c++-native"

(though your moving of the binary into a "dbg" package might disturb that. I'd 
create a "utils" package for it)



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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


[yocto] [yocto-autobuilder][PATCH] bin/release_scripts/release.py

2016-05-23 Thread Graydon, Tracy
Remove the step for syncing the staged release to downloads directory. We
pretty much NEVER do the sync to downloads at the time we do staging. Sync
happens much later, as a separate process. We don't need this in the release
script.

Signed-off-by: Graydon, Tracy 
---
 bin/release_scripts/release.py | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/bin/release_scripts/release.py b/bin/release_scripts/release.py
index 3d4ce39..2b4d21c 100755
--- a/bin/release_scripts/release.py
+++ b/bin/release_scripts/release.py
@@ -488,17 +488,7 @@ if __name__ == '__main__':
 print "Generating the master md5sum table."
 gen_rel_md5(RELEASE_DIR, REL_MD5_FILE)
 
-# 8) sync to downloads
-if REL_TYPE == "milestone":
-DL_DIR = os.path.join(DL_BASE, "milestones", RELEASE)
-print "DL_DIR for milestones: %s" %DL_DIR
-else:
-DL_DIR = os.path.join(DL_BASE, RELEASE)
-print "DL_DIR for point/major: %s" %DL_DIR
-print "Publishing release to downloads."
-sync_it(RELEASE_DIR, DL_DIR, "")
-
-# 9) Publish the ADT repo. The default is NOT to publish the ADT. The ADT
+# 8) Publish the ADT repo. The default is NOT to publish the ADT. The ADT
 # is deprecated as of 2.1_M1. However, we need to retain backward
 # compatability for point releases, etc. We do this step after all the 
other
 #  stuff because we want the symlinks to have been converted, extraneous
-- 
2.7.0

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


[yocto] [yocto-autobuilder][PATCH] bin/release_scripts/release.py

2016-05-23 Thread Graydon, Tracy

Fixed the path for the publishing of the eclipse plugins. They were
going to the wrong subdirectory under downloads.

Signed-off-by: Graydon, Tracy 
---
 bin/release_scripts/release.py | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/bin/release_scripts/release.py b/bin/release_scripts/release.py
index 51cd607..3d4ce39 100755
--- a/bin/release_scripts/release.py
+++ b/bin/release_scripts/release.py
@@ -340,18 +340,18 @@ def publish_adt(rel_id, rel_type, opts):
 QEMU_TARGET = os.path.join(ADT_ROOTFS, dirname)
 print "QEMU_SRC: %s" %QEMU_SRC
 sync_it(QEMU_SRC, QEMU_TARGET, "")
-
 sync_it(IPK_DIR, ADT_IPK, "")
 return
 
 if __name__ == '__main__':
-
+
 os.system("clear")
 print
-
+   
 VHOSTS = "/srv/www/vhosts"
 AB_BASE = os.path.join(VHOSTS, "autobuilder.yoctoproject.org/pub/releases")
-DL_BASE = os.path.join(VHOSTS, "downloads.yoctoproject.org/releases/yocto")
+DL_DIR = os.path.join(VHOSTS, "downloads.yoctoproject.org/releases")
+DL_BASE = os.path.join(DL_DIR, "/releases/yocto")
 ADT_BASE = os.path.join(VHOSTS, "adtrepo.yoctoproject.org")
 
 # List of the directories we delete from all releases
@@ -380,7 +380,7 @@ if __name__ == '__main__':
   help="Use when you need to publish the ADT repo to a 
custom location. i.e. python adtcopy -b yocto-2.0_M1.rc1 -a 1.8+snaphot")
 
 (options, args) = parser.parse_args()
-
+ 
 REL_TYPE = ""
 MILESTONE = ""
 if options.poky:
@@ -427,12 +427,12 @@ if __name__ == '__main__':
 print "Build ID is a required argument."
 print "Please use -h or --help for options."
 sys.exit()
-
+   
 if not (RELEASE and RC and REL_ID and REL_TYPE):
 print "Can't determine the release type. Check your args."
 print "You gave me: %s" %options.build
 sys.exit()
-
+
 print "RC_DIR: %s" %RC_DIR
 print "RELEASE: %s" %RELEASE
 print "RC: %s" %RC
@@ -442,7 +442,7 @@ if __name__ == '__main__':
 print "MILESTONE: %s" %MILESTONE
 print
 
-PLUGIN_DIR = os.path.join(DL_BASE, "eclipse-plugin", REL_ID)
+PLUGIN_DIR = os.path.join(DL_DIR, "eclipse-plugin", REL_ID)
 RELEASE_DIR = os.path.join(AB_BASE, RELEASE)
 MACHINES = os.path.join(RELEASE_DIR, "machines")
 BSP_DIR = os.path.join(RELEASE_DIR, 'bsptarballs')
@@ -455,7 +455,7 @@ if __name__ == '__main__':
 # For all releases:
 # 1) Rsync the rc candidate to a staging dir where all work happens
 sync_it(RC_SOURCE, RELEASE_DIR, UNLOVED)
-
+
 # 2) Convert the symlinks in build-appliance dir.
 print "Converting the build-appliance symlink."
 convert_symlinks(BUILD_APP_DIR)
@@ -469,7 +469,7 @@ if __name__ == '__main__':
 nuke_cruft(dirname, CRUFT_LIST)
 print "Generating fresh md5sums."
 gen_md5sum(MACHINES)
-
+
 # For major and point releases
 if REL_TYPE == "major" or REL_TYPE == "point":
 # 4) Fix up the eclipse and poky tarballs
@@ -487,7 +487,7 @@ if __name__ == '__main__':
 # 7) Generate the master md5sum file for the release (for all releases)
 print "Generating the master md5sum table."
 gen_rel_md5(RELEASE_DIR, REL_MD5_FILE)
-
+
 # 8) sync to downloads
 if REL_TYPE == "milestone":
 DL_DIR = os.path.join(DL_BASE, "milestones", RELEASE)
-- 
2.7.0

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


Re: [yocto] errors.yoctoproject

2016-05-23 Thread akuster808


On 05/13/2016 10:59 AM, Khem Raj wrote:
> don’t think so
> 
> just do
> 
> echo `git config --get user.name` > ${HOME}/.oe-send-error
> echo `git config --get user.email` >> ${HOME}/.oe-send-error
> 
> and it should be able to send

thanks. I got it working

- armin
> 
>> On May 13, 2016, at 8:34 AM, akuster808  wrote:
>>
>> Do I need an account enabled to submit to errors.yoctoproject?
>>
>> - armin
>> --
>> ___
>> 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] Newbie Question regarding custom layer and populate_rootfs

2016-05-23 Thread public-hk
Hi Stephan, hi Herrie,

thank you for your replies to my question.

>> So here are the questions:
>> 1) Why my version of the psplash executable - even though it was built -
>> is not installed in the root fs?
> Did you manually build your splash recipe (bitbake psplash-myproject)?
> This does not include it in an image yet. It must be added to image
> features either manually or through a dependency. 
> The psplash-raspberry package seems to be included in the dependencies
> here
> https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/conf/machine/include/rpi-base.inc#n51
>  - maybe there is a chance to override this in your local.conf
> The cleanest way might be to include this in an own machine definition
> and override it afterwards.

I have finally added a machine raspberry2p which includes the original
raspberrypi2 machine definition - and then defines another SPLASH reference.
That worked.

>
>> 2) I have been able to review the logs from build steps and almost
>> everything related to the package creation in tmp/work subfolder of my
>> build project. But how can I see which packages are installed during the
>> populate_rootfs step? There seems to be no dedicated log file.
> There is a rather complex conglomerate of piped commands here, which
> does this: https://community.freescale.com/docs/DOC-94953 

What helped my a lot were the commands

bitbake-layers show-layers and
bitbake -g / && emacs pn-depends.dot

That reference is a really valuable link!

Thank you and best regards

Hauke

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


Re: [yocto] How can I set a recipe that its binaries become available at cross-compile time?

2016-05-23 Thread Jussi Kukkonen
On 23 May 2016 at 16:37,   wrote:
> Hej
>
> I a cmake based application, some code generation via dbusxx-xml2cpp. It is
> provided by the dbuss-c++ lib. A recipe can be found under:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/meta-ivi-demo/recipes-extended/dbus-c++?id=b90c2a20744e1e82b2169a88e68d7677bec907b6

You shouldn't need a separate native recipe: 'BBCLASSEXTEND =
"native"' in the main recipe should work.

> It working and it's compiling & linking, "dbusxx-xml2cpp" is included at the
> native build.
>
> How can I set a recipe that its binaries become available at cross-compile
> time?

If dbus-c++ installs the binaries properly and another recipe depends
on dbus-c++-native then the binaries should be in the native sysroot
during the other recipes build. As an example see dbus-glib and
connman-gnome in oe-core: dbus-glib-native provides dbus-binding-tool
which connman-gnome uses during build.

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


[yocto] How can I set a recipe that its binaries become available at cross-compile time?

2016-05-23 Thread S . Jaritz
Hej

I a cmake based application, some code generation via dbusxx-xml2cpp. It 
is provided by the dbuss-c++ lib. A recipe can be found under:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/meta-ivi-demo/recipes-extended/dbus-c++?id=b90c2a20744e1e82b2169a88e68d7677bec907b6

It working and it's compiling & linking, "dbusxx-xml2cpp" is included at 
the native build.

How can I set a recipe that its binaries become available at cross-compile 
time?

Best regards!

Stefan Jaritz


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 176
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] add generic startup file to yocto image

2016-05-23 Thread Burton, Ross
On 23 May 2016 at 12:36, Alvaro Martinez Tovar  wrote:

> until now I have followed a "manual" methodology to add script to startup
> on system boot:
> - create sh file
> - made it executable and copy it to /etc/init.d
> - add it with update-rc.d my-startup-file.sh defaults 99 to be executed
> just before login prompt.
> What should I do in order to add a generic my-startup-file.sh to
> /etc/init.d and the corresponding S and K file to rcX.d directories?
> Thank you very much for your help!
>

Write a recipe to instal your script using the update-rc.d class to invoke
update-rc.d on install (
http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#ref-classes-update-rc.d
).

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


[yocto] add generic startup file to yocto image

2016-05-23 Thread Alvaro Martinez Tovar
Dear all,until now I have followed a "manual" methodology to add script to 
startup on system boot:- create sh file- made it executable and copy it to 
/etc/init.d- add it with update-rc.d my-startup-file.sh defaults 99 to be 
executed just before login prompt.What should I do in order to add a generic 
my-startup-file.sh to /etc/init.d and the corresponding S and K file to rcX.d 
directories?Thank you very much for your help!BR,alvaro

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


Re: [yocto] [linux-yocto] How to resolve ERROR: ...../poky/meta/recipes-support/libsoup/libsoup-2.4_2.54.1.bb, do_compile) failed with exit code '1'

2016-05-23 Thread Burton, Ross
On 22 May 2016 at 17:35, Gerard Bucas  wrote:

> I am trying to bitbake core-image-sato with Chromium (as per
> https://github.com/ds-hwang/wiki/wiki/build-chromium-on-yocto )
>
> BUT I keep getting a build error on libsoup (using master). Can't seem to
> resolve it.
>

Hi Gerard,

Theres no error in that snippet, can you pastebin the entire log.do_compile
file?

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


Re: [yocto] populate_sysroot error, need SSTATE_DUPWHITELIST variable. How?

2016-05-23 Thread Burton, Ross
On 22 May 2016 at 22:19, Bjorn Sorensen  wrote:

> Its the other way around, actually libftdi builds eeprom. I am still a
> newbie with Yocto and dont have the knowledge to manipulate the builds from
> the recipe like you suggested.
> Although I managed the workaround by adding the SSTATE_DUPWHITELIST
> variable to the recipe and list the conflicting files in the list.
> it all worked out!
>

Did it work on the target?  You've now got two target packages that contain
the same files, so you'll have to be careful that they don't get installed
at the same time, or diverge.  If libftdi builds eeprom, then why do you
need another recipe for ftdi-eeprom?

It really would be best to fix the packaging, instead of working around
broken packaging with SSTATE_DUPWHITELIST.

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


[yocto] useradd.bbclass: Strip trailing ';' in cmd params

2016-05-23 Thread Markus Volk
Hello,

just to mention …

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=553fa35147adb996d515c3d27f62555d9c969cd8
 


results in a do_rootfs loop here if an attached whitspace exists in 
USERADD_PARAM_${PN}

this fixes my problem:
https://github.com/neutrino-hd/meta-neutrino/commit/a8a442ecc1eba1e211c0a16d054f3622045334a5
 


regards,

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