Re: [yocto] [meta-java][PATCH 5/6] bdwgc: import from meta-oe

2017-09-26 Thread Paul Eggleton 
On Wednesday, 27 September 2017 11:14:21 AM NZDT Philip Balister wrote:
> On 09/26/2017 03:59 PM, Paul Eggleton wrote:
> > On Wednesday, 27 September 2017 1:16:19 AM NZDT Philip Balister wrote:
> >> Does the layer index let us search for recipes that depend on another
> >> recipe?
> > 
> > At the moment, no. I have explicitly not done anything with dependencies 
> > because they can be dependent on configuration (e.g. DISTRO_FEATURES, 
> > PACKAGECONFIG) and I haven't taken the time to figure out how to introspect 
> > and present such optional dependencies.
> 
> Thanks Paul. I was wondering since I suspect that over time, the
> question we are asking will become more important. We already ran into a
> similar issue with sip.

Right, the layer index really is the right place to be doing this. I've filed a
bug:

  https://bugzilla.yoctoproject.org/show_bug.cgi?id=12129
 
> Maybe it is time for oe-core-not-so-common-depends?

I'd think we'd want a bit more definition around what goes into such a layer,
that title is pretty vague.

Cheers,
Paul

-- 

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

Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

2017-09-26 Thread Burton, Ross 
On 26 September 2017 at 22:01, Bryan Evenson 
wrote:

> Now this *is* interesting.  Try removing the repeated slashes just in case
> the WSL ln is being incredibly pedantic (ie 
> sstate-build-package//packages-split),
> but I don't seriously expect that to be the problem.  Running stat on the
> source and verifying the destination doesn't exist would be helpful.  Can
> you tell if that is the first ln that it is trying to do, or do many work
> and that one fails?  Does WSL have a working strace or similar to identify
> which exact syscall is failing?
>
>
>
> I am about 60% through the full image build when it gets to glibc-locale
> with about half of the packages for the image fully complete.  I did a stat
> on one of the source files and verified it did exist, and it had 0644 for
> access rights and is owned by me.  I also verified that the destination
> file doesn’t exist.  WSL does have a working strace.  I ran strace on the
> failed cp command shown above and I now have a 56MB strace output file.
> What should I be looking for in this file?
>

Feel free to compress and email it directly to me, but simply grepping for
EINVAL (invalid argument error) might be enough.

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

Re: [yocto] [meta-java][PATCH 5/6] bdwgc: import from meta-oe

2017-09-26 Thread Philip Balister 
On 09/26/2017 03:59 PM, Paul Eggleton wrote:
> On Wednesday, 27 September 2017 1:16:19 AM NZDT Philip Balister wrote:
>> Does the layer index let us search for recipes that depend on another
>> recipe?
> 
> At the moment, no. I have explicitly not done anything with dependencies 
> because they can be dependent on configuration (e.g. DISTRO_FEATURES, 
> PACKAGECONFIG) and I haven't taken the time to figure out how to introspect 
> and present such optional dependencies.

Thanks Paul. I was wondering since I suspect that over time, the
question we are asking will become more important. We already ran into a
similar issue with sip.

Maybe it is time for oe-core-not-so-common-depends?

Philip

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

Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

2017-09-26 Thread Bryan Evenson 
Ross,


From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, September 26, 2017 3:13 PM
To: Bryan Evenson 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash 
on Ubuntu on Windows)

Hi,

On 26 September 2017 at 18:16, Bryan Evenson 
> wrote:
  WARNING: The Linux kernel on your build host was not configured to provide 
process I/O statistics. (CONFIG_TASK_IO_ACCOUNTING is not set)

I searched the Yocto Project documentation and I couldn't figure out what 
specifically these I/O statistics are used for.  What affect does this have on 
my build?  Does anybody know if there is a way to enable I/O statistics for the 
WSL?

That's the buildstats class that is enabled in your local.conf.  I don't expect 
WSL will ever fake a Linux-compatible /proc directory structure, so you can 
just disable this.

OK.  I removed that from my local.conf and the warning went away.


I'm also seeing a very slow refresh of the build status on the command line.  
When multiple tasks are running, I can see the lines clear away from the bottom 
of the screen to the top and then fill in back down.  The resulting flash from 
the refresh makes it nearly impossible to read what some of the running tasks 
are.  What is the actual mechanism for updating the task status on the command 
line?  I'm wondering if it's counting on some feature that Microsoft hasn't 
fully supported yet.

This is just standard curses, so you'll have to wait for Microsoft to make it 
faster.

If you do "bitbake  | cat" then bitbake will fall back to a UI 
that isn't interactive and will be a lot faster.

After I disabled buildstats, the refresh noticeably improved.  From looking at 
buildstats.bbclass, I see a number of ‘stat’ calls.  I’m guessing the stat call 
has some efficiency improvements left to go on WSL.

I am also getting a build error with glibc-locale.  In the do_package stage I'm 
getting a failure in the function sstate_task_postfunc.  The error is on the 
following command:

  cp -afl --preserve=xattr 
/poky/poky-build/tmp/work/armv5e-poky-linux-gnueabi/glibc-locale/2.24-r0/packages-split/*
 
/poky/poky-build/tmp/work/armv5e-poky-linux-gnueabi/glibc-locale/2.24-r0/sstate-build-package//packages-split/*

I am seeing a lot of errors from this command that look like the following:

 cp: cannot create hard link: 
'/poky/poky-build/tmp/work/armv5e-poky-linux-gnueabi/glibc-locale/2.24-r0/sstate-build-package//packages-split/glibc-binary-localedata-ks-in/usr/lib/locale/ks_IN/LC_MEASUREMENT'
 to 
'/poky/poky-build/tmp/work/armv5e-poky-linux-gnueabi/glibc-locale/2.24-r0/packages-split/glibc-binary-localedata-ks-in/usr/lib/locale/ks_IN/LC_MEASUREMENT':
 Invalid argument

I looked at my working directory, and I see that in the source files are there. 
 If I run the cp command from the command line as shown above, I get the same 
errors.  I'm trying to figure out if this is an issue with hard links with WSL 
or if this is general build issue.  Any suggestions on what else to try?

Now this *is* interesting.  Try removing the repeated slashes just in case the 
WSL ln is being incredibly pedantic (ie sstate-build-package//packages-split), 
but I don't seriously expect that to be the problem.  Running stat on the 
source and verifying the destination doesn't exist would be helpful.  Can you 
tell if that is the first ln that it is trying to do, or do many work and that 
one fails?  Does WSL have a working strace or similar to identify which exact 
syscall is failing?

I am about 60% through the full image build when it gets to glibc-locale with 
about half of the packages for the image fully complete.  I did a stat on one 
of the source files and verified it did exist, and it had 0644 for access 
rights and is owned by me.  I also verified that the destination file doesn’t 
exist.  WSL does have a working strace.  I ran strace on the failed cp command 
shown above and I now have a 56MB strace output file.  What should I be looking 
for in this file?

In all honestly I'm surprised you got the build to go as far as you have under 
WSL, that's impressive.  Have you been able to compare performance against a 
full VM on the same hardware?

I haven’t got far enough to do a good performance comparison.  Overall 
performance seems similar, maybe a little slower than against a full VM.

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

Re: [yocto] rootfs encryption support

2017-09-26 Thread Randy MacLeod 

On 2017-09-26 01:25 AM, Kumar, Shrawan wrote:

Hello Team ,

Is it possible to get encrypted rootfs during image build  ?

Currently , I am running “*cryptsetup*” (as sudo) *manually*   after the 
final image(rootfs.ext4) is produced  . The idea is to get this done 
within yocto environment without sudo problem .


Thanks and Regards

Shrawan





I'm not working on it but I think people are trying to focus such work
in this layer:

https://layers.openembedded.org/layerindex/branch/master/layer/meta-encrypted-storage/

   https://github.com/jiazhang0/meta-secure-core


--
# Randy MacLeod.  WR Linux
# Wind River an Intel Company
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

2017-09-26 Thread Josef Holzmayr 

Hi Bryan,

On 26.09.2017 19:16, Bryan Evenson wrote:

Due to what our IT department can support, I am issued a Windows laptop for 
development.  In the past I have used VMWare to make a Linux virtual machine 
for my Yocto Project based image builds and application development.  We are 
starting to get Windows 10 laptops so I am evaluating doing my builds using the 
Windows Subsystem for Linux (WSL) by building a poky/morty image.  Overall it 
seems to be working.  I've had an issue that I've worked through and other 
issues that I'm not quite sure what is going on.


There's obviously a lot of stuff that the WSL does not support (yet) 
which is often filesystems or API limitations. I ran into a list of 
things that they officially marked as known good/bad, but I can't find 
it right now. If it shows up again, I'll forward it. For the time being, 
I think you might be better off looking at CROPS [1] which is the 
"offical" recommendation to buld on Windows/OSX, as far as I can see.


Greetz

[1] https://wiki.yoctoproject.org/wiki/TipsAndTricks/CropsCLIContainers

--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

Re: [yocto] [meta-java][PATCH 5/6] bdwgc: import from meta-oe

2017-09-26 Thread Paul Eggleton 
On Wednesday, 27 September 2017 1:16:19 AM NZDT Philip Balister wrote:
> Does the layer index let us search for recipes that depend on another
> recipe?

At the moment, no. I have explicitly not done anything with dependencies 
because they can be dependent on configuration (e.g. DISTRO_FEATURES, 
PACKAGECONFIG) and I haven't taken the time to figure out how to introspect 
and present such optional dependencies.

Cheers,
Paul

-- 

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

Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

2017-09-26 Thread Burton, Ross 
Hi,

On 26 September 2017 at 18:16, Bryan Evenson 
wrote:

>   WARNING: The Linux kernel on your build host was not configured to
> provide process I/O statistics. (CONFIG_TASK_IO_ACCOUNTING is not set)
>
> I searched the Yocto Project documentation and I couldn't figure out what
> specifically these I/O statistics are used for.  What affect does this have
> on my build?  Does anybody know if there is a way to enable I/O statistics
> for the WSL?
>

That's the buildstats class that is enabled in your local.conf.  I don't
expect WSL will ever fake a Linux-compatible /proc directory structure, so
you can just disable this.


> I'm also seeing a very slow refresh of the build status on the command
> line.  When multiple tasks are running, I can see the lines clear away from
> the bottom of the screen to the top and then fill in back down.  The
> resulting flash from the refresh makes it nearly impossible to read what
> some of the running tasks are.  What is the actual mechanism for updating
> the task status on the command line?  I'm wondering if it's counting on
> some feature that Microsoft hasn't fully supported yet.
>

This is just standard curses, so you'll have to wait for Microsoft to make
it faster.

If you do "bitbake  | cat" then bitbake will fall back to a
UI that isn't interactive and will be a lot faster.


> I am also getting a build error with glibc-locale.  In the do_package
> stage I'm getting a failure in the function sstate_task_postfunc.  The
> error is on the following command:
>
>   cp -afl --preserve=xattr /poky/poky-build/
> tmp/work/armv5e-poky-linux-gnueabi/glibc-locale/2.24-r0/packages-split/*
> /poky/poky-build/tmp/work/armv5e-poky-linux-
> gnueabi/glibc-locale/2.24-r0/sstate-build-package//packages-split/*
>
> I am seeing a lot of errors from this command that look like the following:
>
>  cp: cannot create hard link: '/poky/poky-build/
> tmp/work/armv5e-poky-linux-gnueabi/glibc-locale/2.24-r0/
> sstate-build-package//packages-split/glibc-binary-
> localedata-ks-in/usr/lib/locale/ks_IN/LC_MEASUREMENT' to
> '/poky/poky-build/tmp/work/armv5e-poky-linux-
> gnueabi/glibc-locale/2.24-r0/packages-split/glibc-binary-
> localedata-ks-in/usr/lib/locale/ks_IN/LC_MEASUREMENT': Invalid argument
>
> I looked at my working directory, and I see that in the source files are
> there.  If I run the cp command from the command line as shown above, I get
> the same errors.  I'm trying to figure out if this is an issue with hard
> links with WSL or if this is general build issue.  Any suggestions on what
> else to try?
>

Now this *is* interesting.  Try removing the repeated slashes just in case
the WSL ln is being incredibly pedantic (ie
sstate-build-package//packages-split), but I don't seriously expect that to
be the problem.  Running stat on the source and verifying the destination
doesn't exist would be helpful.  Can you tell if that is the first ln that
it is trying to do, or do many work and that one fails?  Does WSL have a
working strace or similar to identify which exact syscall is failing?

In all honestly I'm surprised you got the build to go as far as you have
under WSL, that's impressive.  Have you been able to compare performance
against a full VM on the same hardware?

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

Re: [yocto] [EXTERNAL] Re: rootfs encryption support

2017-09-26 Thread John Finley 
On Tue, Sep 26, 2017 at 5:06 AM, Kumar, Shrawan 
wrote:

> When I execute the cryptsetup manually (with sudo ) on the host , I could
> see " demomap" getting populated . This confirms that it works on  host
> when I run manually and that HOST configuration is OK .
> However this is not happing under yocto fakeroot environment and it says "
> Cannot initialize device-mapper. Is dm_mod kernel module loaded?*"
>
> @:~$ ls -l /dev/mapper/
> total 0
> crw--- 1 root root 10, 236 Sep 15 02:26 control
> lrwxrwxrwx 1 root root   7 Sep 26 11:56 demomap -> ../dm-7
> lrwxrwxrwx 1 root root   7 Sep 15 02:26 vg00-lv2swap -> ../dm-6
> lrwxrwxrwx 1 root root   7 Sep 15 02:26 vg00-lvdocker -> ../dm-1
> lrwxrwxrwx 1 root root   7 Sep 15 02:26 vg00-lvhome -> ../dm-3
> lrwxrwxrwx 1 root root   7 Sep 15 02:26 vg00-lvroot -> ../dm-2
> lrwxrwxrwx 1 root root   7 Sep 15 02:26 vg00-lvswap -> ../dm-5
> lrwxrwxrwx 1 root root   7 Sep 15 02:26 vg00-lvvar -> ../dm-4
> lrwxrwxrwx 1 root root   7 Sep 15 02:26 vgdata-lvdata -> ../dm-0
>
>
> off course , dm_mod which I could confirm with emty output of  lsmod |
> grep dm_mod
> But then how does it works on host when I run cryptsetup manually ?
>
> I could see " dm_crypt" module is loaded .
>

I could not get around needing sudo, and ended up enabling passwordless
sudo for the user doing the build. Inside the fakerooted function, pieces
that don't require sudo look like this:
cryptsetup luksFormat ...
while others that do require sudo look like this:
PSEUDO_UNLOAD=1 sudo cryptsetup open ...
The PSEUDO_UNLOAD might just be cosmetic in that it prevents a warning
about not being able to load libpseudo.so; I don't remember if it's
actually required. But it does make it clear that the command done by the
sudo is not in the fakeroot environment.

The root of the problem is that going through device mapper requires real
root, fakeroot doesn't give you that, and luks (as far as I can tell) can
only work through device mapper. You might be about to write your own luks
header with the keys, encrypt it sector-by-sector yourself, blah blah blah.

I *did* want to see if I could avoid luks altogether: encrypt it raw using
an image postprocessing command, then at runtime map it with dm-crypt (vs.
luks), but never got around to it. That should be possible without sudo,
and not having luks seems like it would be okay for many embedded uses.


> -Original Message-
> From: Ayoub Zaki [mailto:ayoub.z...@embexus.com]
> Sent: Tuesday, September 26, 2017 4:17 PM
> To: Kumar, Shrawan 
> Subject: [EXTERNAL] Re: [yocto] rootfs encryption support
>
>
>
> On 26.09.2017 12:29, Kumar, Shrawan wrote:
> > To add further information to the query , I am executing  "cryptsetup"
> >  from a recipe as below : (/Yocto 2.0.2)/
> >
> > fakeroot do_install() {
> >
> >cryptsetup --type=plain open hello.enc demomap <
> > dm-crypt-key
> >
> > }
> >
> > Additional debug log :
> >
> > + do_install
> >
> > | + cryptsetup --type=plain open
> > /path_to/tmp/work/cortexa9hf-vfp-neon-elina-linux-gnueabi/DM-CryptSetu
> > p/1.0-r0/hello.enc
> > demomap
> >
> > | *Cannot initialize device-mapper. Is dm_mod kernel module loaded?*
> >
> > |
> >
> > | Cannot initialize device-mapper. Is dm_mod kernel module loaded?
> >
> > | + bb_exit_handler
> >
> *||**Your Host kernel need to have support for DM-Crypt enabled, you can
> autoload the corresponding kernel module by adding to your build host
> modules configuration:
>
> $ sudo sh -c 'echo dm_mod > /etc/modules-load.d/dm_mod.conf'*
> ||
> **
> >
> > Ideally , I was under impression that "fakeroot" shall have allowed to
> > me achieve the goal.
> >
> > Thanks & Regads
> >
> > Shrawan
> >
> > *From:* Kumar, Shrawan
> > *Sent:* Tuesday, September 26, 2017 10:56 AM
> > *To:* 'yocto@yoctoproject.org' 
> > *Subject:* rootfs encryption support
> >
> > Hello Team ,
> >
> > Is it possible to get encrypted rootfs during image build  ?
> >
> > Currently , I am running "*cryptsetup*" (as sudo) *manually*   after
> > the final image(rootfs.ext4) is produced  . The idea is to get this
> > done within yocto environment without sudo problem .
> >
> > Thanks and Regards
> >
> > Shrawan
> >
> >
> >
>
> --
> Ayoub Zaki
> Embedded Systems Consultant
>
> Vaihinger Straße 2/1
> D-71634 Ludwigsburg
>
> Tel. : +4971415074546
> Mobile   : +4917662901545
> Email: ayoub.z...@embexus.com
> Homepage : https://clicktime.symantec.com/a/1/
> 8fQ575pM7qUybRZBFjM9C7WPhR2dXT1R4k3d_4A9BOc=?d=Tm5cGpFBEW_vK6_eBrh-lyBQV_
> R1miTaoqmkTnsHhnTjNs9fOY92cq9wfN5CbL76p9_yEC-
> LnqRTAKlF1fzjPCBupycsjT3GP6G75yD1UVlxZ7c2mqLgkyrhClC1V-
> 74zP2Zbhs8BAnSEhpjJoqPP_0JU1Lzuo-iK8U_D7B1zQes8b4JBgf3DPo21HUsMa2qEG
> MbeqEDq7LU4y2SXKadgb1xcCNmOTvQIJ9LchpVyTITF0Qw2c5M1--o9oWn7FlThc-
> KBs5TLfBKAIexE3ndzKZOdu9D2NlCmcrEM7q1Oe8sarufZ71B8FsfvU5lT_
>

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

2017-09-26 Thread pokybuild 

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


https://autobuilder.yocto.io/pub/releases/yocto-2.4.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 9bf043497c48c45c425081989d142c68968a1385 
meta-qt4 : f313dbee2ac3d5fcc9801407947d3cb6cfb90b5d 
refkit : 74adaf3deaf89e2e800c8baa5e2e5e013d1fc121 
meta-mingw : 52515d8bee445d728d5fe63bfcbca79b5d8ea250 
meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f 
meta-gplv2 : 4bed302b143c4d869f83fcc34b0c1ad1dd143c2d 
poky : 592c3449697ce39bf07864fafd7f0a61ca230561 

\nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: 
git://git.yoctoproject.org/yocto-autobuilder\nEmail: joshua.g.l...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Pruning poky-contrib Oct 1st

2017-09-26 Thread Michael Halstead 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello poky-contrib users,

We are going to start regularly moving branches from poky-contrib to
poky-contrib-archive that haven't been active for 1 year.

The next move will happen on October 1st. Please prune any branch that
should not be archived before the 1st.

If you have branches that need to stay in place but are no longer
receiving updates please update the list at
https://wiki.yoctoproject.org/wiki/Poky_Contrib or e-mail me. For
example, you might need a branch to stay where it is because it is
referenced in documentation.

- -- 
Michael Halstead
Linux Foundation / SysAdmin

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEzowQ2UYmQerfiW8/amSWNbpCWpUFAlnKaMcACgkQamSWNbpC
WpWw8hAAm+FTba/EK1NYz4CQJbTG08iiOPiqHm9oO8wlmAswigL6HrBJ5TDsgIVh
FdkKcEpGhvHVlGfWZsUFAEUKayd4+5oCKg9zOST9/4lDc9SHbyAtf587POmVYVz2
P3r+423CJY2vkH8Xp3xl1zJAmRIUGpwWQqJu2ERcLxfjGWgQy5fhgFo7zX8vMPOa
8ONzbpF5lWO86DtAzErCeerS6ZTkC0lOzMyhARXE6XPFh+nb+AvMY5ewCPVbCRQK
ilK0YfjKIGv1tJ4g4zfsa2Lbexp6lsI3lWvPGjwFYZvWXB/OKAE0iSUtuWimepDQ
8mm633tVEk5tuksCYU7CRox2xiU9oYlCV2pFp3HKBnIxkxOyhoFYYiE7PdTC8Tp5
dRpOGzyiEU38en2UlDiq+Uc26kW8GGIHnp0ku0FCAWxPI0ioPusTpV2iZm1lwGnl
ydweOAyNPOo9cD5kjo19dnWjUYtxty1vjtz4F2iTobJgenmxFjDrmUmCYnNYZmQu
Ayt+s5n9/kr/CXOzfCHQO+Xal9kPXI1bhKapFhk4rWg0/5hSypm5J24BT1jSTjgw
amGMeZgbn3jOEBMehpPHvJ0OMXfBJfstTgD5UUCIwtc1tpbPxAbKKZz2GK/yqLeL
j8ztjW8TmSfmnuBWGeDM9ObotRIYz8M+E+tsl+VHzfCmTXusPVk=
=TNB2
-END PGP SIGNATURE-
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-oracle-java][PATCH] Revert "oracle-jse-ejre: Fix destination" (4eb10648f31539f95110852496b987db6f74df55)

2017-09-26 Thread Vincent Prince 
We need to add JRE directly in ${JDK_JRE}${PV}_${PV_UPDATE} as oracle-jse.inc 
installs all dest folder.

Without this patch JRE is installed in /usr/lib/jvm/java-8-oracle/jre/bin/java 
and /usr/bin/java points to
/usr/lib/jvm/java-8-oracle/bin/java

Signed-off-by: Vincent Prince 
---
 recipes-devtools/oracle-java/oracle-jse-ejre.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-devtools/oracle-java/oracle-jse-ejre.inc 
b/recipes-devtools/oracle-java/oracle-jse-ejre.inc
index 0af0b6b..d7a4b33 100644
--- a/recipes-devtools/oracle-java/oracle-jse-ejre.inc
+++ b/recipes-devtools/oracle-java/oracle-jse-ejre.inc
@@ -19,7 +19,7 @@ LIC_FILES_CHKSUM = "\
"
 
 do_compile() {
-   DEST=${S}/ejre${PV}_${PV_UPDATE}/jre
+   DEST=${S}/${JDK_JRE}${PV}_${PV_UPDATE}
rm -rf ${DEST}
JAVA_HOME=${STAGING_DIR_NATIVE}/${JDK_HOME} 
ejdk${PV}_${PV_UPDATE}/bin/jrecreate.sh --dest ${DEST}
 }
-- 
2.7.4

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

Re: [yocto] [infra] git domain name updates

2017-09-26 Thread Michael Halstead 


On 09/25/2017 06:17 PM, akuster808 wrote:
> 
> 
> On 09/25/2017 05:17 PM, Michael Halstead wrote:
>> Hello,
>>
>> As Yocto Project continues to grow load on our git server does as
>> well. We are going to make a few changes to our git infrastructure to
>> allow for more growth.
>>
>> All read-only git operations should point at git.yoctoproject.org. For
>> example poky can be cloned from the following URLs:
>>
>> git://git.yoctoproject.org/poky
>> https://git.yoctoproject.org/git/poky
>>
>> If you have repositories pointed at www.yoctoproject.org,
>> git.pokylinux.org, or any other domain name please update their remotes
>> to git.yoctoproject.org.
>>
>> Read-write operations via ssh will use a new domain specifically for
>> that purpose. I've added push.yoctoproject.org and ra.yoctoproject.org
>> (like ra.kernel.org).
>>
>     Read-write URLs should be updated to the new domain names. I've
>> changed mine like so:
>>
>>
>> git remote set-url origin ssh://g...@push.yoctoproject.org/poky-contrib
>>
>>
> will this apply  to the other contrib repos hosted by Yocto?

This will apply to all repos hosted at git.yoctoproject.org. I used
poky-contrib as the push example since it has the most users.

> 
> Is there a policy on pruning old branches in the contrib repos?
> 

There hasn't been a policy but we need to create one. I've checked with
Richard and we will move branches to poky-contrib-archive that haven't
been touched in a year. I'll send out a notice about that.

> 
>> This is all ready to go right now. Please update your remotes.
>>
>> We will have to make these changes required before we can start to get
>> performance benefits from them. I suggest November 1st 2017 but I need
>> more feedback before we can set a cut off date.
> sounds good to me. Thanks for working on this.
> 
> - armin
>>
>> Thank you,
>>
> 
> 

-- 
Michael Halstead
Linux Foundation / SysAdmin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [infra] git domain name updates

2017-09-26 Thread Michael Halstead 


On 09/26/2017 03:27 AM, Burton, Ross wrote:
> On 26 September 2017 at 01:17, Michael Halstead
> >
> wrote:
> 
> This is all ready to go right now. Please update your remotes.
> 

Read-write users:

While updating your git remotes you may also need to update
configuration in ~/.ssh/config or /etc/ssh/ssh_config with the new
domain name.

If you use several ssh keys or work behind a proxy you probably have
configuration to update.

grep yoctoproject ~/.ssh/config /etc/ssh/ssh_config
/etc/ssh/ssh_config.d/*.conf

If you see git.yoctoproject.org change it to push.yoctoproject.org.

Remember to check for any build accounts you've created as well as your
main account.

-- 
Michael Halstead
Linux Foundation / SysAdmin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-java][PATCH 5/6] bdwgc: import from meta-oe

2017-09-26 Thread Philip Balister 
On 09/26/2017 04:19 AM, Maxin B. John wrote:
> Hi Philip,
> 
> On Mon, Sep 25, 2017 at 4:05 PM, Philip Balister  wrote:
>> On 09/24/2017 05:05 PM, Maxin B. John wrote:
>>> keep a copy of bdwgc recipe in meta-java from meta-oe layer.
>>> cacao in meta-java depends on bdwgc.
>>
>> Duplicating recipes in recipes is frowned upon.
> 
> Thanks for the review. Makes sense here. Will try to find a way to avoid this.
> 
>> Shouldn't we have the discussion why you are  not proposing this for
>> Openembedded-core instead of duplicating the recipe? Duping a recipe
>> just to drop a layer dependency isn't a long term solution.
> 
> agree.

Meta-oe has one recipe that uses it. I'm not sure about other layers.

Does the layer index let us search for recipes that depend on another
recipe?

Philip

> 
>> Philip
> 
> Best Regards,
> Maxin
> 
>>>
>>> Signed-off-by: Maxin B. John 
>>> ---
>>>  ...ac-add-check-for-NO_GETCONTEXT-definition.patch | 29 +++
>>>  recipes-extended/bdwgc/bdwgc/musl_header_fix.patch | 27 ++
>>>  recipes-extended/bdwgc/bdwgc_7.6.0.bb  | 42 
>>> ++
>>>  3 files changed, 98 insertions(+)
>>>  create mode 100644 
>>> recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
>>>  create mode 100644 recipes-extended/bdwgc/bdwgc/musl_header_fix.patch
>>>  create mode 100644 recipes-extended/bdwgc/bdwgc_7.6.0.bb
>>>
>>> diff --git 
>>> a/recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
>>>  
>>> b/recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
>>> new file mode 100644
>>> index 000..8ef774f
>>> --- /dev/null
>>> +++ 
>>> b/recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
>>> @@ -0,0 +1,29 @@
>>> +configure.ac: add check for NO_GETCONTEXT definition
>>> +
>>> +Signed-off-by: Samuel Martin 
>>> +[yann.morin.1...@free.fr: add a comment, change variable name, use
>>> + AS_IF, remove debug traces, use AC_CHECK_FUNCS (as suggested by
>>> + Thomas)]
>>> +Signed-off-by: "Yann E. MORIN" 
>>> +Cc: Thomas Petazzoni 
>>> +
>>> +---
>>> +Upstream-Status: Pending
>>> + configure.ac | 6 ++
>>> + 1 file changed, 6 insertions(+)
>>> +
>>> +--- bdwgc-7.2f.orig/configure.ac 2014-06-01 19:00:47.0 +0200
>>>  bdwgc-7.2f/configure.ac  2014-12-23 14:13:11.585716713 +0100
>>> +@@ -365,6 +365,12 @@
>>> +   AC_MSG_RESULT($ac_cv_fno_strict_aliasing)
>>> + fi
>>> +
>>> ++# Check for getcontext (uClibc can be configured without it, for example)
>>> ++AC_CHECK_FUNCS([getcontext])
>>> ++AS_IF([test "$ac_cv_func_getcontext" = "no"],
>>> ++  [CFLAGS="$CFLAGS -DNO_GETCONTEXT"
>>> ++   CPPFLAGS="$CPPFLAGS -DNO_GETCONTEXT"])
>>> ++
>>> + case "$host" in
>>> + # While IRIX 6 has libdl for the O32 and N32 ABIs, it's missing for N64
>>> + # and unnecessary everywhere.
>>> diff --git a/recipes-extended/bdwgc/bdwgc/musl_header_fix.patch 
>>> b/recipes-extended/bdwgc/bdwgc/musl_header_fix.patch
>>> new file mode 100644
>>> index 000..4a18496
>>> --- /dev/null
>>> +++ b/recipes-extended/bdwgc/bdwgc/musl_header_fix.patch
>>> @@ -0,0 +1,27 @@
>>> +Add missing header to avoid:
>>> +
>>> +| 1472659610.016355: ../git/pthread_stop_world.c: In function 
>>> 'GC_brief_async_signal_safe_sleep':
>>> +| 1472659610.0540252: ../git/pthread_stop_world.c:397:22: error: storage 
>>> size of 'tv' isn't known
>>> +| 1472659610.0540252:struct timeval tv;
>>> +| 1472659610.0540252:   ^~
>>> +| 1472659610.054099: ../git/pthread_stop_world.c:397:22: warning: unused 
>>> variable 'tv' [-Wunused-variable]
>>> +| 1472659610.054099:struct timeval tv;
>>> +| 1472659610.054099:   ^~
>>> +| 1472659610.054099: Makefile:1530: recipe for target 
>>> 'pthread_stop_world.lo' failed
>>> +
>>> +in musl builds.
>>> +
>>> +Upstream-Status: Pending
>>> +
>>> +Index: git/pthread_stop_world.c
>>> +===
>>> +--- git.orig/pthread_stop_world.c
>>>  git/pthread_stop_world.c
>>> +@@ -45,6 +45,7 @@
>>> + #include 
>>> + #include 
>>> + #include 
>>> ++#include 
>>> + #include "atomic_ops.h"
>>> +
>>> + /* It's safe to call original pthread_sigmask() here.   */
>>> diff --git a/recipes-extended/bdwgc/bdwgc_7.6.0.bb 
>>> b/recipes-extended/bdwgc/bdwgc_7.6.0.bb
>>> new file mode 100644
>>> index 000..dcb68f0
>>> --- /dev/null
>>> +++ b/recipes-extended/bdwgc/bdwgc_7.6.0.bb
>>> @@ -0,0 +1,42 @@
>>> +SUMMARY = "A garbage collector for C and C++"
>>> +
>>> +DESCRIPTION = "The Boehm-Demers-Weiser conservative garbage collector can 
>>> be\
>>> + used as a garbage collecting replacement for C malloc or C++ new. It 
>>> allows\
>>> + you to allocate memory basically as you normally would, without 
>>> explicitly\

[yocto] Kernel change in YOCTO

2017-09-26 Thread Zoran Stojsavljevic 
Hello,

I have a bit dummy question. I have older Pyro distro, compiled for
qemux86_64. It has there kernel 4.10.17, and there are two interesting
directories, where one can find definitions of the kernels:

[user@localhost poky]$ find . -name *.bbappend
...
./meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend
./meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.10.bbappend
./meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend <<===
Introduced later
./meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend
./meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.9.bbappend
...

And the .bb scripts are located in:
./meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
./meta/recipes-kernel/linux/linux-dummy.bb
./meta/recipes-kernel/linux/linux-yocto_4.9.bb
./meta/recipes-kernel/linux/linux-yocto_4.1.bb
./meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
./meta/recipes-kernel/linux/linux-yocto-dev.bb
./meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb
./meta/recipes-kernel/linux/linux-generic_4.13.3.bb <<=== Introduced later
(git HEAD checkout)
./meta/recipes-kernel/linux/linux-yocto-tiny_4.9.bb
./meta/recipes-kernel/linux/linux-yocto_4.10.bb
./meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
./meta/recipes-kernel/linux/linux-yocto-rt_4.9.bb
./meta/recipes-kernel/linux/linux-yocto_4.4.bb
./meta/recipes-kernel/linux/linux-yocto_4.12.bb <<=== Introduced later
./meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
./meta/recipes-kernel/linux/kernel-devsrc.bb

Whatever I did (introduced kernel_4.12.12 with the same set of the scripts
from master - different git headers), I was not able to switch kernel while
building qemux86-64!?

Even at the end (in desperation to understand from where dependencies are
coming) I deleted .git in poky/, and deleted everything in build/, except
conf/bbappend.conf and conf/local.conf?!

But still, kernel 4.10.17 is always taken... No idea why?

user@localhost build]$ bitbake -c fetchall core-image-sato
WARNING: Host distribution "fedora-26" has not been validated with this
version of the build system; you may possibly experience unexpected
failures. It is recommended that you use a tested distribution.
Loading cache: 100%
|#|
Time: 0:00:01
Loaded 1300 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "x86_64-poky-linux"
MACHINE   = "qemux86-64"
DISTRO= "poky"
DISTRO_VERSION= "2.3.1"
TUNE_FEATURES = "m64 core2"
TARGET_FPU= ""
meta
meta-poky
*meta-yocto-bsp= ":" <<=== .git deleted prior
fetching*

Initialising tasks: 100%
||
Time: 0:00:18
NOTE: Executing RunQueue Tasks

Summary: There were 11 WARNING messages shown.
[user@localhost build]$
___

Questions:
[1] Should I blindly follow:
http://www.yoctoproject.org/docs/2.3.2/kernel-dev/kernel-
dev.html#creating-and-preparing-a-layer
Where it is written that new layer must be introduced for the new kernel,
also (after layer and scripts creation) placed in
.../build/conf/bbappend.conf?

[2] If [1] is a must, where I can read about reasons why this requirement
exists?? Maybe BSP and kernel have some invisible dependencies??

[3] Where are these invisible kernel dependencies? So is there something
(?) kernel depends on, although I always believed that everything else is
dependent on kernel (kernel is HW dependend via device drivers), since
kernel lives on its own (except some BSP data - kernel command line passed
to it at the boot time, which should have no influence on dependency of any
kind between kernel boot-loader and kernel itself)?!

Thank you,
Zoran
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] rootfs encryption support

2017-09-26 Thread Ayoub Zaki 

Hi,

On 26.09.2017 12:29, Kumar, Shrawan wrote:
To add further information to the query , I am executing  “cryptsetup” 
 from a recipe as below : (/Yocto 2.0.2)/


fakeroot do_install() {

   cryptsetup --type=plain open hello.enc demomap < 
dm-crypt-key


}

Additional debug log :

+ do_install

| + cryptsetup --type=plain open 
/path_to/tmp/work/cortexa9hf-vfp-neon-elina-linux-gnueabi/DM-CryptSetup/1.0-r0/hello.enc 
demomap


| *Cannot initialize device-mapper. Is dm_mod kernel module loaded?*

|

| Cannot initialize device-mapper. Is dm_mod kernel module loaded?

| + bb_exit_handler

Your Host kernel need to have support for DM-Crypt enabled, you can 
autoload the corresponding kernel module by adding to your build host 
modules configuration:


$ sudo sh -c 'echo dm_mod > /etc/modules-load.d/dm_mod.conf'



Ideally , I was under impression that “fakeroot” shall have allowed to 
me achieve the goal.


Thanks & Regads

Shrawan

*From:* Kumar, Shrawan
*Sent:* Tuesday, September 26, 2017 10:56 AM
*To:* 'yocto@yoctoproject.org' 
*Subject:* rootfs encryption support

Hello Team ,

Is it possible to get encrypted rootfs during image build  ?

Currently , I am running “*cryptsetup*” (as sudo) *manually*   after 
the final image(rootfs.ext4) is produced  . The idea is to get this 
done within yocto environment without sudo problem .


Thanks and Regards

Shrawan




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

Re: [yocto] rootfs encryption support

2017-09-26 Thread Kumar, Shrawan 


To add further information to the query , I am executing  "cryptsetup"  from a 
recipe as below : (Yocto 2.0.2)


fakeroot do_install() {
   cryptsetup --type=plain open hello.enc demomap < dm-crypt-key

}


Additional debug log :

+ do_install
| + cryptsetup --type=plain open 
/path_to/tmp/work/cortexa9hf-vfp-neon-elina-linux-gnueabi/DM-CryptSetup/1.0-r0/hello.enc
 demomap
| Cannot initialize device-mapper. Is dm_mod kernel module loaded?
|
| Cannot initialize device-mapper. Is dm_mod kernel module loaded?
| + bb_exit_handler


Ideally , I was under impression that "fakeroot" shall have allowed to me 
achieve the goal.



Thanks & Regads
Shrawan

From: Kumar, Shrawan
Sent: Tuesday, September 26, 2017 10:56 AM
To: 'yocto@yoctoproject.org' 
Subject: rootfs encryption support

Hello Team ,

Is it possible to get encrypted rootfs during image build  ?

Currently , I am running "cryptsetup" (as sudo) manually   after the final 
image(rootfs.ext4) is produced  . The idea is to get this done within yocto 
environment without sudo problem .


Thanks and Regards
Shrawan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [infra] git domain name updates

2017-09-26 Thread Burton, Ross 
On 26 September 2017 at 01:17, Michael Halstead <
mhalst...@linuxfoundation.org> wrote:

> This is all ready to go right now. Please update your remotes.
>

For people who don't know, you can configure convenience URL aliases in
git.  Here's a little config fragment for ~/.gitconfig to give an alias
which will use the git: server for pulls and ssh: for pushes:

[url "ssh://g...@push.yoctoproject.org/"]
pushInsteadOf = yocto:
[url "git://git.yoctoproject.org/"]
insteadOf = yocto:

With this the URL you need to clone anything from the Yocto server is just
yocto:module.  For example:

$ git clone yocto:poky
$ cd poky
$ git remote add contrib yocto:poky-contrib

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

Re: [yocto] [yocto-infrastructure] [infra] git domain name updates

2017-09-26 Thread Richard Purdie 
On Mon, 2017-09-25 at 17:17 -0700, Michael Halstead wrote:
> This is all ready to go right now. Please update your remotes.
> 
> We will have to make these changes required before we can start to
> get performance benefits from them. I suggest November 1st 2017 but I
> need more feedback before we can set a cut off date.

I'd be tempted just to go ahead and do this sooner than later if you we
stand people asking questions about why it stopped working for them...

My .git/config files were full of rather elderly data but I think I
have all my main usages updated now...

Cheers,

Richard



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

Re: [yocto] [meta-java][PATCH 5/6] bdwgc: import from meta-oe

2017-09-26 Thread Maxin B. John 
Hi Philip,

On Mon, Sep 25, 2017 at 4:05 PM, Philip Balister  wrote:
> On 09/24/2017 05:05 PM, Maxin B. John wrote:
>> keep a copy of bdwgc recipe in meta-java from meta-oe layer.
>> cacao in meta-java depends on bdwgc.
>
> Duplicating recipes in recipes is frowned upon.

Thanks for the review. Makes sense here. Will try to find a way to avoid this.

> Shouldn't we have the discussion why you are  not proposing this for
> Openembedded-core instead of duplicating the recipe? Duping a recipe
> just to drop a layer dependency isn't a long term solution.

agree.

> Philip

Best Regards,
Maxin

>>
>> Signed-off-by: Maxin B. John 
>> ---
>>  ...ac-add-check-for-NO_GETCONTEXT-definition.patch | 29 +++
>>  recipes-extended/bdwgc/bdwgc/musl_header_fix.patch | 27 ++
>>  recipes-extended/bdwgc/bdwgc_7.6.0.bb  | 42 
>> ++
>>  3 files changed, 98 insertions(+)
>>  create mode 100644 
>> recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
>>  create mode 100644 recipes-extended/bdwgc/bdwgc/musl_header_fix.patch
>>  create mode 100644 recipes-extended/bdwgc/bdwgc_7.6.0.bb
>>
>> diff --git 
>> a/recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
>>  
>> b/recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
>> new file mode 100644
>> index 000..8ef774f
>> --- /dev/null
>> +++ 
>> b/recipes-extended/bdwgc/bdwgc/0001-configure.ac-add-check-for-NO_GETCONTEXT-definition.patch
>> @@ -0,0 +1,29 @@
>> +configure.ac: add check for NO_GETCONTEXT definition
>> +
>> +Signed-off-by: Samuel Martin 
>> +[yann.morin.1...@free.fr: add a comment, change variable name, use
>> + AS_IF, remove debug traces, use AC_CHECK_FUNCS (as suggested by
>> + Thomas)]
>> +Signed-off-by: "Yann E. MORIN" 
>> +Cc: Thomas Petazzoni 
>> +
>> +---
>> +Upstream-Status: Pending
>> + configure.ac | 6 ++
>> + 1 file changed, 6 insertions(+)
>> +
>> +--- bdwgc-7.2f.orig/configure.ac 2014-06-01 19:00:47.0 +0200
>>  bdwgc-7.2f/configure.ac  2014-12-23 14:13:11.585716713 +0100
>> +@@ -365,6 +365,12 @@
>> +   AC_MSG_RESULT($ac_cv_fno_strict_aliasing)
>> + fi
>> +
>> ++# Check for getcontext (uClibc can be configured without it, for example)
>> ++AC_CHECK_FUNCS([getcontext])
>> ++AS_IF([test "$ac_cv_func_getcontext" = "no"],
>> ++  [CFLAGS="$CFLAGS -DNO_GETCONTEXT"
>> ++   CPPFLAGS="$CPPFLAGS -DNO_GETCONTEXT"])
>> ++
>> + case "$host" in
>> + # While IRIX 6 has libdl for the O32 and N32 ABIs, it's missing for N64
>> + # and unnecessary everywhere.
>> diff --git a/recipes-extended/bdwgc/bdwgc/musl_header_fix.patch 
>> b/recipes-extended/bdwgc/bdwgc/musl_header_fix.patch
>> new file mode 100644
>> index 000..4a18496
>> --- /dev/null
>> +++ b/recipes-extended/bdwgc/bdwgc/musl_header_fix.patch
>> @@ -0,0 +1,27 @@
>> +Add missing header to avoid:
>> +
>> +| 1472659610.016355: ../git/pthread_stop_world.c: In function 
>> 'GC_brief_async_signal_safe_sleep':
>> +| 1472659610.0540252: ../git/pthread_stop_world.c:397:22: error: storage 
>> size of 'tv' isn't known
>> +| 1472659610.0540252:struct timeval tv;
>> +| 1472659610.0540252:   ^~
>> +| 1472659610.054099: ../git/pthread_stop_world.c:397:22: warning: unused 
>> variable 'tv' [-Wunused-variable]
>> +| 1472659610.054099:struct timeval tv;
>> +| 1472659610.054099:   ^~
>> +| 1472659610.054099: Makefile:1530: recipe for target 
>> 'pthread_stop_world.lo' failed
>> +
>> +in musl builds.
>> +
>> +Upstream-Status: Pending
>> +
>> +Index: git/pthread_stop_world.c
>> +===
>> +--- git.orig/pthread_stop_world.c
>>  git/pthread_stop_world.c
>> +@@ -45,6 +45,7 @@
>> + #include 
>> + #include 
>> + #include 
>> ++#include 
>> + #include "atomic_ops.h"
>> +
>> + /* It's safe to call original pthread_sigmask() here.   */
>> diff --git a/recipes-extended/bdwgc/bdwgc_7.6.0.bb 
>> b/recipes-extended/bdwgc/bdwgc_7.6.0.bb
>> new file mode 100644
>> index 000..dcb68f0
>> --- /dev/null
>> +++ b/recipes-extended/bdwgc/bdwgc_7.6.0.bb
>> @@ -0,0 +1,42 @@
>> +SUMMARY = "A garbage collector for C and C++"
>> +
>> +DESCRIPTION = "The Boehm-Demers-Weiser conservative garbage collector can 
>> be\
>> + used as a garbage collecting replacement for C malloc or C++ new. It 
>> allows\
>> + you to allocate memory basically as you normally would, without explicitly\
>> + deallocating memory that is no longer useful. The collector automatically\
>> + recycles memory when it determines that it can no longer be otherwise\
>> + accessed.\
>> +  The collector is also used by a number of programming language\
>> + implementations that either use C as intermediate code, want to facilitate\
>> + easier

[yocto] [meta-gplv2][PATCH] elfutils: Make it build with GCC 7 and compile time hardening enabled

2017-09-26 Thread Peter Kjellerstedt 
Signed-off-by: Peter Kjellerstedt 
---
 .../0001-Make-it-compile-with-GCC-7.patch  | 43 ++
 ...ld-with-GCC-7-and-compile-time-hardening-.patch | 32 
 recipes-devtools/elfutils/elfutils_0.148.bb|  2 +
 3 files changed, 77 insertions(+)
 create mode 100644 
recipes-devtools/elfutils/elfutils-0.148/0001-Make-it-compile-with-GCC-7.patch
 create mode 100644 
recipes-devtools/elfutils/elfutils-0.148/0002-Make-it-build-with-GCC-7-and-compile-time-hardening-.patch

diff --git 
a/recipes-devtools/elfutils/elfutils-0.148/0001-Make-it-compile-with-GCC-7.patch
 
b/recipes-devtools/elfutils/elfutils-0.148/0001-Make-it-compile-with-GCC-7.patch
new file mode 100644
index 000..a43508f
--- /dev/null
+++ 
b/recipes-devtools/elfutils/elfutils-0.148/0001-Make-it-compile-with-GCC-7.patch
@@ -0,0 +1,43 @@
+From 9529f012a1cfdae36aedeab8ccd790c875ae7f73 Mon Sep 17 00:00:00 2001
+From: Peter Kjellerstedt 
+Date: Sat, 16 Sep 2017 15:09:23 +0200
+Subject: [PATCH 1/2] Make it compile with GCC 7
+
+This avoids the following errors:
+
+  src/readelf.c: In function 'register_info':
+  src/readelf.c:4481:30: warning: 'sizeof' on array function parameter
+  'name' will return size of 'char *' [-Wsizeof-array-argument]
+ snprintf (name, sizeof name, "reg%u", loc->regno);
+^~~~
+  src/readelf.c:4472:14: note: declared here
+   char name[REGNAMESZ], int *bits, int *type)
+^~~~
+  rc/readelf.c:4481:30: warning: argument to 'sizeof' in 'snprintf' call
+  is the same expression as the destination; did you mean to provide an
+  explicit length? [-Wsizeof-pointer-memaccess]
+ snprintf (name, sizeof name, "reg%u", loc->regno);
+^~~~
+
+Upstream-Status: Inappropriate [legacy version]
+Signed-off-by: Peter Kjellerstedt 
+---
+ src/readelf.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/readelf.c b/src/readelf.c
+index bf622a6..ba0607b 100644
+--- a/src/readelf.c
 b/src/readelf.c
+@@ -4478,7 +4478,7 @@ register_info (Ebl *ebl, unsigned int regno, const 
Ebl_Register_Location *loc,
+bits ?: , type ?: );
+   if (n <= 0)
+ {
+-  snprintf (name, sizeof name, "reg%u", loc->regno);
++  snprintf (name, REGNAMESZ, "reg%u", loc->regno);
+   if (bits != NULL)
+   *bits = loc->bits;
+   if (type != NULL)
+-- 
+2.12.0
+
diff --git 
a/recipes-devtools/elfutils/elfutils-0.148/0002-Make-it-build-with-GCC-7-and-compile-time-hardening-.patch
 
b/recipes-devtools/elfutils/elfutils-0.148/0002-Make-it-build-with-GCC-7-and-compile-time-hardening-.patch
new file mode 100644
index 000..68d14b6
--- /dev/null
+++ 
b/recipes-devtools/elfutils/elfutils-0.148/0002-Make-it-build-with-GCC-7-and-compile-time-hardening-.patch
@@ -0,0 +1,32 @@
+From 5dcd8e331af448e3adcb9ed15a38762a912a8267 Mon Sep 17 00:00:00 2001
+From: Peter Kjellerstedt 
+Date: Sat, 16 Sep 2017 15:12:37 +0200
+Subject: [PATCH 2/2] Make it build with GCC 7 and compile time hardening
+ enabled
+
+This avoids the following error:
+
+cc1: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
+
+Upstream-Status: Inappropriate [legacy version]
+Signed-off-by: Peter Kjellerstedt 
+---
+ config/eu.am | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/config/eu.am b/config/eu.am
+index 8066d7f..7de66b0 100644
+--- a/config/eu.am
 b/config/eu.am
+@@ -33,7 +33,7 @@ INCLUDES = -I. -I$(srcdir) -I$(top_srcdir)/lib -I..
+ AM_CFLAGS = -std=gnu99 -Wall -Wshadow \
+   $(if $($(*F)_no_Werror),,-Werror) \
+   $(if $($(*F)_no_Wunused),,-Wunused $(WEXTRA)) \
+-  $(if $($(*F)_no_Wformat),-Wno-format,-Wformat=2) \
++  $(if $($(*F)_no_Wformat),-Wno-format 
-Wno-format-security,-Wformat=2) \
+   $($(*F)_CFLAGS)
+ 
+ if MUDFLAP
+-- 
+2.12.0
+
diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb 
b/recipes-devtools/elfutils/elfutils_0.148.bb
index 29d109a..892a523 100644
--- a/recipes-devtools/elfutils/elfutils_0.148.bb
+++ b/recipes-devtools/elfutils/elfutils_0.148.bb
@@ -37,6 +37,8 @@ SRC_URI += "\
 file://gcc6.patch \
 file://0001-Fix-fallthrough-warnings.patch \
 file://0002-Fix-printf-overflow-warnings.patch \
+file://0001-Make-it-compile-with-GCC-7.patch \
+file://0002-Make-it-build-with-GCC-7-and-compile-time-hardening-.patch 
\
 "
 # Only apply when building uclibc based target recipe
 SRC_URI_append_libc-uclibc = " file://uclibc-support-for-elfutils-0.148.patch"
-- 
2.12.0

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