date:20160825

Re: [yocto] [yocto-autobuilder][PATCH] nightly-wic.conf: add additional config settings for efi images

2016-08-25 Thread Beth 'pidge' Flanagan

On Wed, 2016-08-24 at 10:40 -0700, Bill Randle wrote:
> Building efi disk images now requires extra config settings, so add
> IMAGE_FSTYPES and MACHINE_FEATURES appends to the auto.conf file.
> 
> Signed-off-by: Bill Randle 
> 

Merged to master.

-b

> ---
>  buildset-config.controller/nightly-wic.conf | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/buildset-config.controller/nightly-wic.conf b/buildset-
> config.controller/nightly-wic.conf
> index 1b91852..14e2411 100644
> --- a/buildset-config.controller/nightly-wic.conf
> +++ b/buildset-config.controller/nightly-wic.conf
> @@ -9,24 +9,24 @@ steps: [{'SetDest':{}},
>  {'RunPreamble':{}},
>  {'GetDistroVersion':{'distro': 'poky'}},
>  {'CreateBBLayersConf':{'buildprovider':'yocto'}},
> -{'CreateAutoConf':{'machine':'qemux86'}},
> +{'CreateAutoConf':{'machine':'qemux86',
> 'atextappend':'\nIMAGE_FSTYPES += " hddimg"\nMACHINE_FEATURES_append
> = " efi"\n'}},
>  {'BuildImages':{'images':'syslinux syslinux-native parted-
> native gptfdisk-native dosfstools-native mtools-native'}},
>  {'BuildImages':{'images':'core-image-sato'}},
>  {'CreateWicImages':{'wic_img_type':'directdisk',
> 'target_img':'core-image-sato'}},
>  {'CreateWicImages':{'wic_img_type':'directdisk-gpt',
> 'target_img':'core-image-sato'}},
>  {'CreateWicImages':{'wic_img_type':'mkefidisk',
> 'target_img':'core-image-sato'}},
> -{'CreateAutoConf':{'machine':'genericx86'}},
> +{'CreateAutoConf':{'machine':'genericx86',
> 'atextappend':'\nIMAGE_FSTYPES += " hddimg"\nMACHINE_FEATURES_append
> = " efi"\n'}},
>  {'BuildImages':{'images':'syslinux syslinux-native parted-
> native gptfdisk-native dosfstools-native mtools-native'}},
>  {'BuildImages':{'images':'core-image-sato'}},
>  {'CreateWicImages':{'wic_img_type':'directdisk',
> 'target_img':'core-image-sato'}},
>  {'CreateWicImages':{'wic_img_type':'directdisk-gpt',
> 'target_img':'core-image-sato'}},
>  {'CreateWicImages':{'wic_img_type':'mkefidisk',
> 'target_img':'core-image-sato'}},
> -{'CreateAutoConf':{'machine':'qemux86-64'}},
> +{'CreateAutoConf':{'machine':'qemux86-64',
> 'atextappend':'\nIMAGE_FSTYPES += " hddimg"\nMACHINE_FEATURES_append
> = " efi"\n'}},
>  {'BuildImages':{'images':'syslinux syslinux-native parted-
> native gptfdisk-native dosfstools-native mtools-native'}},
>  {'BuildImages':{'images':'core-image-sato'}},
>  {'CreateWicImages':{'wic_img_type':'directdisk',
> 'target_img':'core-image-sato'}},
>  {'CreateWicImages':{'wic_img_type':'directdisk-gpt',
> 'target_img':'core-image-sato'}},
> -{'CreateAutoConf':{'machine':'genericx86-64'}},
> +{'CreateAutoConf':{'machine':'genericx86-64',
> 'atextappend':'\nIMAGE_FSTYPES += " hddimg"\nMACHINE_FEATURES_append
> = " efi"\n'}},
>  {'BuildImages':{'images':'syslinux syslinux-native parted-
> native gptfdisk-native dosfstools-native mtools-native'}},
>  {'BuildImages':{'images':'core-image-sato'}},
>  {'CreateWicImages':{'wic_img_type':'directdisk',
> 'target_img':'core-image-sato'}},
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Problem to get Host packages.

2016-08-25 Thread TinTin Naing

I just followed the steps in Yocto Project Quick Start Guide and tried to get 
host packages download using following command:

* $ sudo apt-get install gawk wget git-core diffstat unzip texinfo 
gcc-multilib \
 build-essential chrpath socat libsdl1.2-dev xterm

The following error comes out.
Please advise how to solve.
Note: I am using VM BOX to install  yocto project.

[cid:image001.jpg@01D1FEF5.73CDE110]

Thanks and Best Regards,

[cid:image002.jpg@01D1FEF5.73CDE110]

Name: TIN TIN NAING
Designation:R&D ENGINEER
Function
WPG South Asia Pte. Ltd.
*   DID : (65) 6470-1453 * Office : (65) 6282-5188 ext: 11453
*   MOBILE : (65) 914720316  Fax : (65) 6280-4988
*  Email :  tintin.na...@sa.wpgholdings.com

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

Re: [yocto] Package mono-libs-4.5 size increase in Mono version 4.4.x

2016-08-25 Thread Alex J Lennon



On 18/08/2016 03:19, Craig McQueen wrote:
> I wrote:
>> I've just had to upgrade from Mono 4.2.x to Mono 4.4.x, to get a fix for SMTP
>> SSL/TLS.
>>
>> I'm using the mono-libs-4.5 package. I see that the size of it has increased
>> quite a lot (several MB) due to the upgrade. It looks as though it's now
>> putting a bunch of files in /usr/lib/mono/4.5-api in addition to the old
>> /usr/lib/mono/4.5.
>>
>> I can see this mentioned in the Mono 4.4.0 release notes:
>> http://www.mono-project.com/docs/about-mono/releases/4.4.0/
>>
>> But the rationale is not entirely clear to me. Is it possible to cut down the
>> Yocto image size by removing one of /usr/lib/mono/4.5-api and
>> /usr/lib/mono/4.5, or some other refactoring?
> It looks as though, in my image for the device, I only need /usr/lib/mono/4.5.
>
> In my custom layer, I've made a mono_4.4.%.bbappend file which contains:
>
> # Split /usr/lib/mono/4.5-api off into a separate package.
> PACKAGES += "${PN}-libs-4.5-api"
> 
> FILES_${PN}-libs-4.5-api= "${libdir}/mono/4.5-api/*"
> FILES_${PN}-libs-4.5= "${libdir}/mono/4.5/*"
>
> My image includes the package mono-libs-4.5 (as it did before when I was 
> using Mono 4.2.x). Now the image size is back to near what it was for Mono 
> 4.2.x, and everything on the target device seems to be running fine.
>

Thanks Craig. I'll take a look at adding this in

Cheers, Alex

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

[yocto] How to add a textline to the busybox-syslog syslog.conf?

2016-08-25 Thread S . Jaritz

Hej ho

I have an app that is using syslog. For it I like to set the amount of log 
data.

I am using the std. yocto(krogoth) together with the std. meta-atmel 
layer. This layers are installing the "busybox-syslog"-package. This comes 
with the "/etc/syslog.conf" file.

My question is: How to append the syslog.conf with a line like 
"myApp,auth.notice /var/log/messages" out of a recipe?

My idea of the dummy recipe looks like:
 myApp.bb 
SUMMARY = "myApp"
SECTION = "demo"
LICENSE = "GPL"

inherit cmake

DEPENDS = "busybox-syslog"

SRC_URI = "gitsm://mygit/myApp.git;protocol=http;branch=develop"

PV = "1.0.0"

S = "${WORKDIR}/git/"

BBCLASSEXTEND = "native nativesdk"

do_install_append() {
echo 'myApp.*   /var/log/messages' >> /etc/syslog.conf
}
#

Any ideas how to do it in a nice way?

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

[yocto] [prelink-cross][PATCH] rtld: Add missing DT_NEEDED DSOs to needed_list

2016-08-25 Thread Kyle Russell

prelink-rtld may report an "error while loading shared libraries" for
the wrong library.

If some set of DT_NEEDED DSOs are not in the default search path, they
may have a dso_list entry added, but no matching entry is added to the
needed_list.  This causes the linker to miscalculate the max number of
dsos during build_local_scope(), which later causes find_needed() to not
search the entire l_local_scope[0]->r_list during
_dl_check_map_versions() (since the max from build_local_scope() becomes
l_local_scope[0]->r_nlist).

Since find_needed() searches through the r_list, which would have the
dso_list entries for the libraries that weren't found earlier, this cuts
the search short, meaning libraries near the end of the local scope don't
get included in the map version search.

As the comment in _dl_check_map_versions() suggests, if needed is NULL,
that means a dependency was not found and no stub entry created, which
should never happen.

Signed-off-by: Kyle Russell 
---
 src/rtld/rtld.c | 36 ++--
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/src/rtld/rtld.c b/src/rtld/rtld.c
index 8d7d760..d9a0862 100644
--- a/src/rtld/rtld.c
+++ b/src/rtld/rtld.c
@@ -686,6 +686,25 @@ find_lib_by_soname (const char *soname, struct dso_list 
*loader,
   return NULL;
 }
 
+static void
+add_dso_to_needed (struct dso_list *cur_dso_ent, struct dso_list *new_dso_ent)
+{
+  if (!cur_dso_ent->needed)
+{
+  cur_dso_ent->needed = malloc (sizeof (struct needed_list));
+  cur_dso_ent->needed_tail = cur_dso_ent->needed;
+  cur_dso_ent->needed_tail->ent = new_dso_ent;
+  cur_dso_ent->needed_tail->next = NULL;
+}
+  else if (!in_needed_list (cur_dso_ent->needed, new_dso_ent->name))
+{
+  cur_dso_ent->needed_tail->next = malloc (sizeof (struct needed_list));
+  cur_dso_ent->needed_tail = cur_dso_ent->needed_tail->next;
+  cur_dso_ent->needed_tail->ent = new_dso_ent;
+  cur_dso_ent->needed_tail->next = NULL;
+}
+}
+
 static struct dso_list *
 load_dsos (DSO *dso, int host_paths)
 {
@@ -812,6 +831,8 @@ load_dsos (DSO *dso, int host_paths)
  dso_list_tail->canon_filename = strdup(soname);
  dso_list_tail->err_no = errno;
 
+  add_dso_to_needed(cur_dso_ent, new_dso_ent);
+
  continue;
}
 
@@ -854,20 +875,7 @@ load_dsos (DSO *dso, int host_paths)
dso_list_tail->name = new_dso->soname;
}
 
- if (!cur_dso_ent->needed)
-   {
- cur_dso_ent->needed = malloc (sizeof (struct 
needed_list));
- cur_dso_ent->needed_tail = cur_dso_ent->needed;
- cur_dso_ent->needed_tail->ent = new_dso_ent;
- cur_dso_ent->needed_tail->next = NULL;
-   }
- else if (!in_needed_list (cur_dso_ent->needed, soname))
-   {
- cur_dso_ent->needed_tail->next = malloc (sizeof (struct 
needed_list));
- cur_dso_ent->needed_tail = cur_dso_ent->needed_tail->next;
- cur_dso_ent->needed_tail->ent = new_dso_ent;
- cur_dso_ent->needed_tail->next = NULL;
-   }
+  add_dso_to_needed(cur_dso_ent, new_dso_ent);
 
  continue;
}
-- 
2.7.4

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

Re: [yocto] OpenEmbedded Metadata: Recipe update broken

2016-08-25 Thread Andreas Müller

On Wed, Jul 13, 2016 at 6:00 AM, Paul Eggleton
 wrote:
> On Fri, 19 Feb 2016 08:05:09 Andreas Müller wrote:
>> On Wed, Feb 3, 2016 at 9:06 PM, Andreas Müller
>>  wrote:
>> > On Wed, Feb 3, 2016 at 8:10 PM, Paul Eggleton
>> >  wrote:
>> >> On Wed, 03 Feb 2016 14:41:42 Andreas Müller wrote:
>> >>> FAQ for layerindex says recipes are updated every 3 hours but I think
>> >>> it does not work. E.g meta-oe geis/grail/frame are not mentioned but
>> >>> were committed few days ago.
>> >>
>> >> I do know there's a problem, but I'm honestly not sure what's causing it.
>> >> Unfortunately I don't have time to dig into it now but let me see if I
>> >> can resync meta-oe at least.
>> >
>> > No need for manual update - it was just a heads up. I was not sure
>> > that it is a known issue.
>>
>> I checked in history:
>>
>> meta-openwrt added 4 weeks ago is the last layer for that was
>> analyzed. meta-cpan and all published after that were not analysed
>> anymore - they are reported having no recipes.
>>
>> As this is a strong tool I have at daily use: Is there something I can
>> do to get this working again?
>
> So, it was a long time coming, but I finally figured out what was going wrong
> at least for some cases - basically, newer versions of GitPython actually
> recognise renamed files instead of treating them as an add and a delete, but
> since I didn't know about this change I didn't fix the layer index code to
> accommodate this. With the recent layer index upgrade to support Python 3 for
> master, the fix for this issue was also applied, and each layer is also now
> parsed in a separate subprocess which should finally take care of memory leaks
> and any other rubbish being left behind affecting parsing of subsequent
> layers. Hopefully we shouldn't see any more of this type of problem again
> (aside from actually broken metadata) but as always please do let me know if
> you see anything strange.
>
> Cheers,
> Paul
>
Hi,

seems layer list update is broken again e.g I am committing on
meta-qt5-extra regularly but last commit reported is one month ago.

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

[yocto] systemd-networkd

2016-08-25 Thread C. Handel

   hi,

i'm trying to build an image with systemd that runs systemd-networkd to
initialize the network.

So far it boots, the interface goes up and it receives an IP via dhcp.

I now try to update my hostname from the one received by dhcp. As far as i
understand systemd, the systemd-networkd sends a dbus message, this will
trigger systemd-hostnamed. The setting of the hostname is protected by
polkit. This is all configured. I can see the message on the bus and is
also see the log entry of hostnamed. But the hostname does not change

Aug 25 16:29:08 genericx86-64 systemd-networkd[203]: enp0s3: Gained carrier
Aug 25 16:29:08 genericx86-64 systemd[1]: Starting Hostname Service...
Aug 25 16:29:08 genericx86-64 systemd[1]: Starting Authorization Manager...
Aug 25 16:29:08 genericx86-64 systemd-hostnamed[216]: Changed host name to
'vm009'


Did I miss anything?

Greetings
   Christoph



the bbappend for systemd

FILESEXTRAPATHS_append := "${THISDIR}/files:"
SRC_URI += "file://eth.network"

FILES_${PN} += "{sysconfdir}/systemd/network/*"

PACKAGECONFIG += "networkd resolved timesyncd hostnamed polkit myhostname"

# for version 230 yocto fixes this
# networkd requires a user
USERADD_PARAM_${PN} += "--system -d / -M --shell /bin/nologin
systemd-network;"
# resolved requires a user
USERADD_PARAM_${PN} += "--system -d / -M --shell /bin/nologin
systemd-resolve;"
# timesyncd requires a user
USERADD_PARAM_${PN} += "--system -d / -M --shell /bin/nologin
systemd-timesync;"

do_install_append() {
  install -d ${D}${sysconfdir}/systemd/network/
  install -m 0644 ${WORKDIR}/*.network ${D}${sysconfdir}/systemd/network/
}



and the eth.network


[Match]
Name=en*

[Network]
DHCP=ipv4

[DHCP]
UseDNS=true
UseNTP=true
UseHostname=true
UseDomains=true
UseRoutes=true
# otherwise a uuid is generated and we only assign via MAC address
ClientIdentifier=mac
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [prelink-cross][PATCH] rtld: Add missing DT_NEEDED DSOs to needed_list

2016-08-25 Thread Mark Hatle

Thanks!  I'll try to get this included soon.

--Mark

On 8/25/16 10:39 AM, Kyle Russell wrote:
> prelink-rtld may report an "error while loading shared libraries" for
> the wrong library.
> 
> If some set of DT_NEEDED DSOs are not in the default search path, they
> may have a dso_list entry added, but no matching entry is added to the
> needed_list.  This causes the linker to miscalculate the max number of
> dsos during build_local_scope(), which later causes find_needed() to not
> search the entire l_local_scope[0]->r_list during
> _dl_check_map_versions() (since the max from build_local_scope() becomes
> l_local_scope[0]->r_nlist).
> 
> Since find_needed() searches through the r_list, which would have the
> dso_list entries for the libraries that weren't found earlier, this cuts
> the search short, meaning libraries near the end of the local scope don't
> get included in the map version search.
> 
> As the comment in _dl_check_map_versions() suggests, if needed is NULL,
> that means a dependency was not found and no stub entry created, which
> should never happen.
> 
> Signed-off-by: Kyle Russell 
> ---
>  src/rtld/rtld.c | 36 ++--
>  1 file changed, 22 insertions(+), 14 deletions(-)
> 
> diff --git a/src/rtld/rtld.c b/src/rtld/rtld.c
> index 8d7d760..d9a0862 100644
> --- a/src/rtld/rtld.c
> +++ b/src/rtld/rtld.c
> @@ -686,6 +686,25 @@ find_lib_by_soname (const char *soname, struct dso_list 
> *loader,
>return NULL;
>  }
>  
> +static void
> +add_dso_to_needed (struct dso_list *cur_dso_ent, struct dso_list 
> *new_dso_ent)
> +{
> +  if (!cur_dso_ent->needed)
> +{
> +  cur_dso_ent->needed = malloc (sizeof (struct needed_list));
> +  cur_dso_ent->needed_tail = cur_dso_ent->needed;
> +  cur_dso_ent->needed_tail->ent = new_dso_ent;
> +  cur_dso_ent->needed_tail->next = NULL;
> +}
> +  else if (!in_needed_list (cur_dso_ent->needed, new_dso_ent->name))
> +{
> +  cur_dso_ent->needed_tail->next = malloc (sizeof (struct needed_list));
> +  cur_dso_ent->needed_tail = cur_dso_ent->needed_tail->next;
> +  cur_dso_ent->needed_tail->ent = new_dso_ent;
> +  cur_dso_ent->needed_tail->next = NULL;
> +}
> +}
> +
>  static struct dso_list *
>  load_dsos (DSO *dso, int host_paths)
>  {
> @@ -812,6 +831,8 @@ load_dsos (DSO *dso, int host_paths)
> dso_list_tail->canon_filename = strdup(soname);
> dso_list_tail->err_no = errno;
>  
> +  add_dso_to_needed(cur_dso_ent, new_dso_ent);
> +
> continue;
>   }
>  
> @@ -854,20 +875,7 @@ load_dsos (DSO *dso, int host_paths)
>   dso_list_tail->name = new_dso->soname;
>   }
>  
> -   if (!cur_dso_ent->needed)
> - {
> -   cur_dso_ent->needed = malloc (sizeof (struct 
> needed_list));
> -   cur_dso_ent->needed_tail = cur_dso_ent->needed;
> -   cur_dso_ent->needed_tail->ent = new_dso_ent;
> -   cur_dso_ent->needed_tail->next = NULL;
> - }
> -   else if (!in_needed_list (cur_dso_ent->needed, soname))
> - {
> -   cur_dso_ent->needed_tail->next = malloc (sizeof (struct 
> needed_list));
> -   cur_dso_ent->needed_tail = cur_dso_ent->needed_tail->next;
> -   cur_dso_ent->needed_tail->ent = new_dso_ent;
> -   cur_dso_ent->needed_tail->next = NULL;
> - }
> +  add_dso_to_needed(cur_dso_ent, new_dso_ent);
>  
> continue;
>   }
> 

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

Re: [yocto] How to add a textline to the busybox-syslog syslog.conf?

2016-08-25 Thread Khem Raj


> On Aug 25, 2016, at 3:58 AM, s.jar...@esa-grimma.de wrote:
> 
> Hej ho
> 
> I have an app that is using syslog. For it I like to set the amount of log 
> data.
> 
> I am using the std. yocto(krogoth) together with the std. meta-atmel layer. 
> This layers are installing the "busybox-syslog"-package. This comes with the 
> "/etc/syslog.conf" file.
> 
> My question is: How to append the syslog.conf with a line like 
> "myApp,auth.notice /var/log/messages" out of a recipe?

you can write a bbappend for busybox recipe in your own layer and add 
do_install_append there



> 
> My idea of the dummy recipe looks like:
>  myApp.bb 
> SUMMARY = "myApp"
> SECTION = "demo"
> LICENSE = "GPL"
> 
> inherit cmake
> 
> DEPENDS = "busybox-syslog"
> 
> SRC_URI = "gitsm://mygit/myApp.git;protocol=http;branch=develop"
> 
> PV = "1.0.0"
> 
> S = "${WORKDIR}/git/"
> 
> BBCLASSEXTEND = "native nativesdk"
> 
> do_install_append() {
> echo 'myApp.*/var/log/messages' >> /etc/syslog.conf
> }
> #
> 
> Any ideas how to do it in a nice way?
> 
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] problem with yocto and qt5

2016-08-25 Thread milad hasanvand

Dear all,

i have frustrating issue with compiling qt5 using yocto and it is
definitely going to kill me.
i am using qemux86 as the target. i attached the bblayers.conf and
local.conf. i also added the -qpa eglfs to packageconfig but it fails when
it comes to do-configure task of qt base.
please help me out because it has almost been two months since i stuck with
this problem.


bblayers.conf
Description: Binary data


local.conf
Description: Binary data
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] problem with yocto and qt5

2016-08-25 Thread Khem Raj

On Wed, Aug 24, 2016 at 2:26 AM, milad hasanvand
 wrote:
> Dear all,
>
> i have frustrating issue with compiling qt5 using yocto and it is definitely
> going to kill me.
> i am using qemux86 as the target. i attached the bblayers.conf and
> local.conf. i also added the -qpa eglfs to packageconfig but it fails when
> it comes to do-configure task of qt base.

How does it fail ? perhaps you should share the logs and messages so
someone might
relate to the error

> please help me out because it has almost been two months since i stuck with
> this problem.
>
>
> --
> ___
> 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] Git/yocto newbie question re: submodules and multiple layers

2016-08-25 Thread Michael Habibi

Hi, I am well-versed with Git but I haven't really ever had to use
submodules. I am trying to create a git repository on our server that
will host our yocto distribution. Our distribution will include the
yocto repo, plus meta-openembedded repo, plus maybe some other layers.

The difficulty I have is thus:

my_git_repo/ <--- what my platform developers will 'git clone'
my_git_repo/yocto_git/... <-- yocto framework
my_git_repo/yocto_git/meta-openembedded <-- another git repo nested
inside yocto repo
my_git_repo/yocto_git/meta-intel <-- another example layer.

I would like for developers to be able to 'git clone' a single repo,
but pull down all the necessary layers from various git repos.
Basically it will comprise all repos, including yocto, OE layers,
intel layers, etc.

I believe the only way I can nest submodules inside pre-existing repos
is for me to create a local clone of yocto git and add the submodules
to that clone. That means the master git repo (my_git_repo in example
above) will point to *our* clone of yocto git and not yocto project's
git repo. In our local clone of yocto git, I will add a submodule for
each layer I want to add.

Does that make sense? Is this the right approach or is there a smarter way?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Git/yocto newbie question re: submodules and multiple layers

2016-08-25 Thread Khem Raj


> On Aug 25, 2016, at 2:24 PM, Michael Habibi  wrote:
> 
> Hi, I am well-versed with Git but I haven't really ever had to use
> submodules. I am trying to create a git repository on our server that
> will host our yocto distribution. Our distribution will include the
> yocto repo, plus meta-openembedded repo, plus maybe some other layers.
> 
> The difficulty I have is thus:
> 
> my_git_repo/ <--- what my platform developers will 'git clone'
> my_git_repo/yocto_git/... <-- yocto framework
> my_git_repo/yocto_git/meta-openembedded <-- another git repo nested
> inside yocto repo
> my_git_repo/yocto_git/meta-intel <-- another example layer.
> 
> I would like for developers to be able to 'git clone' a single repo,
> but pull down all the necessary layers from various git repos.
> Basically it will comprise all repos, including yocto, OE layers,
> intel layers, etc.
> 
> I believe the only way I can nest submodules inside pre-existing repos
> is for me to create a local clone of yocto git and add the submodules
> to that clone. That means the master git repo (my_git_repo in example
> above) will point to *our* clone of yocto git and not yocto project's
> git repo. In our local clone of yocto git, I will add a submodule for
> each layer I want to add.
> 
> Does that make sense? Is this the right approach or is there a smarter way?

There are several ways to setup your workspace.

1. Use android repo tool you can look at the angstrom distro which is OE/yocto
based (https://github.com/Angstrom-distribution/angstrom-manifest)

2. you can use combo-tool from Yocto project ( which is used by poky distro )
3. you can use git submodules which is used by BEC distro again based on
OE (https://github.com/cbrake/oe-build)

you can also do something else may be use jiri ( 
https://github.com/vanadium/go.jiri )



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



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OpenEmbedded Metadata: Recipe update broken

2016-08-25 Thread Paul Eggleton

On Thu, 25 Aug 2016 18:14:23 Andreas Müller wrote:
> On Wed, Jul 13, 2016 at 6:00 AM, Paul Eggleton
>  wrote:
> > On Fri, 19 Feb 2016 08:05:09 Andreas Müller wrote:
> >> On Wed, Feb 3, 2016 at 9:06 PM, Andreas Müller
> >>  wrote:
> >> > On Wed, Feb 3, 2016 at 8:10 PM, Paul Eggleton
> >> > 
> >> >  wrote:
> >> >> On Wed, 03 Feb 2016 14:41:42 Andreas Müller wrote:
> >> >>> FAQ for layerindex says recipes are updated every 3 hours but I think
> >> >>> it does not work. E.g meta-oe geis/grail/frame are not mentioned but
> >> >>> were committed few days ago.
> >> >> 
> >> >> I do know there's a problem, but I'm honestly not sure what's causing
> >> >> it.
> >> >> Unfortunately I don't have time to dig into it now but let me see if I
> >> >> can resync meta-oe at least.
> >> > 
> >> > No need for manual update - it was just a heads up. I was not sure
> >> > that it is a known issue.
> >> 
> >> I checked in history:
> >> 
> >> meta-openwrt added 4 weeks ago is the last layer for that was
> >> analyzed. meta-cpan and all published after that were not analysed
> >> anymore - they are reported having no recipes.
> >> 
> >> As this is a strong tool I have at daily use: Is there something I can
> >> do to get this working again?
> > 
> > So, it was a long time coming, but I finally figured out what was going
> > wrong at least for some cases - basically, newer versions of GitPython
> > actually recognise renamed files instead of treating them as an add and a
> > delete, but since I didn't know about this change I didn't fix the layer
> > index code to accommodate this. With the recent layer index upgrade to
> > support Python 3 for master, the fix for this issue was also applied, and
> > each layer is also now parsed in a separate subprocess which should
> > finally take care of memory leaks and any other rubbish being left behind
> > affecting parsing of subsequent layers. Hopefully we shouldn't see any
> > more of this type of problem again (aside from actually broken metadata)
> > but as always please do let me know if you see anything strange.
> 
> seems layer list update is broken again e.g I am committing on
> meta-qt5-extra regularly but last commit reported is one month ago.

Michael, I'm still not receiving any layer index update script emails. Is 
there a way we can fix that so I can see what might be going wrong?

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Git/yocto newbie question re: submodules and multiple layers

2016-08-25 Thread Anders Darander

* Michael Habibi  [160825 23:26]:

> The difficulty I have is thus:

> my_git_repo/ <--- what my platform developers will 'git clone'
> my_git_repo/yocto_git/... <-- yocto framework
> my_git_repo/yocto_git/meta-openembedded <-- another git repo nested
> inside yocto repo

> my_git_repo/yocto_git/meta-intel <-- another example layer.

> I would like for developers to be able to 'git clone' a single repo,
> but pull down all the necessary layers from various git repos.
> Basically it will comprise all repos, including yocto, OE layers,
> intel layers, etc.

> I believe the only way I can nest submodules inside pre-existing repos
> is for me to create a local clone of yocto git and add the submodules
> to that clone. That means the master git repo (my_git_repo in example
> above) will point to *our* clone of yocto git and not yocto project's
> git repo. In our local clone of yocto git, I will add a submodule for
> each layer I want to add.

> Does that make sense? Is this the right approach or is there a smarter way?

I'm using submodules, but I put them like:

my_git_repo/ <--- what my platform developers will 'git clone'
my_git_repo/yocto_git/... <-- yocto framework
my_git_repo/meta-openembedded 

Well, I'm using bitbake and openembedded-core repos directly instead of
yocto, but that doesn't really matter.

Cheers,
Anders

-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder][PATCH] nightly-wic.conf: add additional config settings for efi images

[yocto] Problem to get Host packages.

Re: [yocto] Package mono-libs-4.5 size increase in Mono version 4.4.x

[yocto] How to add a textline to the busybox-syslog syslog.conf?

[yocto] [prelink-cross][PATCH] rtld: Add missing DT_NEEDED DSOs to needed_list

Re: [yocto] OpenEmbedded Metadata: Recipe update broken

[yocto] systemd-networkd

Re: [yocto] [prelink-cross][PATCH] rtld: Add missing DT_NEEDED DSOs to needed_list

Re: [yocto] How to add a textline to the busybox-syslog syslog.conf?

[yocto] problem with yocto and qt5

Re: [yocto] problem with yocto and qt5

[yocto] Git/yocto newbie question re: submodules and multiple layers

Re: [yocto] Git/yocto newbie question re: submodules and multiple layers

Re: [yocto] OpenEmbedded Metadata: Recipe update broken

Re: [yocto] Git/yocto newbie question re: submodules and multiple layers

15 matches

Site Navigation

Mail list logo

Footer information