[yocto] Yocto Linux kernel 4.8 boot can't login.

2017-01-11 Thread Richard Zhang 
Hi all


Just a strange error on my login.


With yocto kernel 4.8  and glibc 2.23 from poky 2.1.2, I get this:


setuid: Function not implemented


Is there something incompatible?




Full kernel message:


[3.308503] clocksource: Switched to clocksource tsc
[   12.843922] md: Waiting for all devices to be available before autodetect
[   12.851520] md: If you don't use raid, use raid=noautodetect
[   12.858281] md: Autodetecting RAID arrays.
[   12.862881] md: Scanned 0 and added 0 devices.
[   12.867852] md: autorun ...
[   12.870972] md: ... autorun DONE.
[   12.884091] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: 
(null)
[   12.892693] VFS: Mounted root (ext4 filesystem) on device 8:5.
[   12.902808] devtmpfs: mounted
[   12.910636] Freeing unused kernel memory: 1700K (81d8e000 - 
81f37000)
[   12.919424] Write protecting the kernel read-only data: 12288k
[   12.926662] Freeing unused kernel memory: 140K (8800017dd000 - 
88000180)
[   12.937305] Freeing unused kernel memory: 236K (880001bc5000 - 
880001c0)
INIT: version 2.88 booting
[   13.011380] random: fast init done
Starting udev
[   13.149792] udevd[188]: starting version 3.1.5
[   13.384232] EXT4-fs (sda5): re-mounted. Opts: data=ordered
Populating dev cache
INIT: Entering runlevel: 5
Configuring network interfaces... [   13.826907] IPv6: ADDRCONF(NETDEV_UP): 
eth0: link is not ready
[   13.833442] 8021q: adding VLAN 0 to HW filter on device eth0
udhcpc (v1.24.1) started
Sending discover...
[   16.825226] igb :03:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: RX
Sending discover...
[   16.939960] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending discover...
Sending select for 10.10.51.205...
Lease of 10.10.51.205 obtained, lease time 3600
/etc/udhcpc.d/50default: Adding DNS 10.10.50.10
/etc/udhcpc.d/50default: Adding DNS 8.8.8.8
done.
Starting OpenBSD Secure Shell server: sshd
  generating ssh RSA key...
  generating ssh ECDSA key...
  generating ssh DSA key...
  generating ssh ED25519 key...
done.
Starting ntpd: done
Starting syslogd/klogd: done
Starting crond: setuid: Function not implemented
FAIL

Pica8 PicOS for genericx86-64 Release 2.8.0 Build 
ff4743f1c0a5f23da38bbb341d76cdde 2.8.0 genericx86-64 /dev/ttyS1

genericx86-64 login: root
setgid: Function
Pica8 PicOS for genericx86-64 Release 2.8.0 Build 
ff4743f1c0a5f23da38bbb341d76cdde 2.8.0 genericx86-64 /dev/ttyS1

genericx86-64 login: [  139.302930] random: crng init done





Regards

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

Re: [yocto] [meta-selinux] What's the point of refpolicy-minimum?

2017-01-11 Thread wenzong fan 

On 01/10/2017 10:48 PM, Joe MacDonald wrote:

Wenzong / Shrikant,

I thought I knew the answer to the above question, and maybe my
understanding is still correct, but I think I need to ask it now anyway.

I don't use refpolicy-minimum for anything, so when I did the updates to
refpolicy*_git I didn't even glance at refpolicy-minimum_git.  Wenzong's
change to refpolicy-minimum_2.20161023 (in the same thread as the uprev
of the recipe) piqued my curiosity, so I had a look.  Of course,
refpolicy-minimum_git.bb also needs to be updated (or thrown out), but
now that I'm looking at the recipe I see what seems like conflicting
statements in the recipe:

   recipes-security/refpolicy/refpolicy-minimum_2.20161023.bb:

 1 include refpolicy-targeted_${PV}.bb
 2
 3 SUMMARY = "SELinux minimum policy"
 4 DESCRIPTION = "\
 5 This is a minimum reference policy with just core policy modules, and \
 6 could be used as a base for customizing targeted policy. \
 7 Pretty much everything runs as initrc_t or unconfined_t so all of the \
 8 domains are unconfined. \
 9 "

and:

   recipes-security/refpolicy/refpolicy-targeted_2.20161023.bb:

 1 SUMMARY = "SELinux targeted policy"
 2 DESCRIPTION = "\
 3 This is the targeted variant of the SELinux reference policy.  Most 
service \
 4 domains are locked down. Users and admins will login in with 
unconfined_t \
 5 domain, so they have the same access to the system as if SELinux was not 
\
 6 enabled. \
 7 "

So now I'm trying to understand what the point of refpolicy-minimum
really is here.  Those of you who are using it, what are you using it
for and what do you expect would be the correct behaviour of a system
running that policy?



I don't have much experience on using the refpolicy-minimum as well.

But from the original logs it should be "minimum targeted policy".

commit 65675f02e33f5da31ec5dbac7a45849f4952569b
Author: Wenzong Fan 
Date:   Mon Mar 24 21:07:50 2014 -0400

refpolicy: add minimum targeted policy

This is a minimum targeted policy with just core policy modules, and
could be used as a base for customizing targeted policy.
Pretty much everything runs as initrc_t or unconfined_t so all of the
domains are unconfined.

Signed-off-by: Wenzong Fan 
Signed-off-by: Joe MacDonald 



At the very least, I'm going to remove the 'include [...].bb' from both
'minimum' recipes, as that's completely incorrect, but when I do that I
want to know what anyone using this recipe wants to see from it, so
whatever the 'include' gets replaced with is doing the right thing
(which isn't necessarily what it's doing today).


I won't object to make the changes, if you think there should be a 
different minimum policy with targeted.


Thanks
Wenzong




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

Re: [yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023

2017-01-11 Thread wenzong fan 

On 01/11/2017 09:51 PM, Joe MacDonald wrote:

[Re: [yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023] On 
17.01.11 (Wed 10:24) wenzong fan wrote:


On 01/10/2017 10:25 PM, Joe MacDonald wrote:

[[yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023] On 17.01.10 
(Tue 00:54) wenzong@windriver.com wrote:


From: Wenzong Fan 

Uprev refpolicy to 2.20161023 and fix build errors for refpolicy-minimum.

The following changes since commit bae51859f0dbcdde9fd563d15128a6dbbb816801:

 audit: upgrade 2.6.6 -> 2.7 (2017-01-09 08:59:55 -0500)

are available in the git repository at:

 git://git.pokylinux.org/poky-contrib wenzong/refpolicy-2.20161023
 
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/refpolicy-2.20161023


As poky-contrib is full of unrelated stuff, it's not the right place to
be doing meta-selinux work AFAICT.  I'd rather you actually just
fork meta-selinux somewhere like github if you plan to send pull
requests.  Patches are fine, of course, they're even easier for me to
work with.


Oko< I didn't notice that before, I'll fork it on github for my pull
requests later.


You don't have to, patches are always fine with me.  I'm just letting
you know that I won't be pulling anything from your poky-contrib
branches for meta-selinux since they're completely different repos.


Ok, I got it:)

Thanks
Wenzong



Thanks Wenzong.
-J.



Thanks
Wenzong



-J.



Wenzong Fan (2):
 refpolicy: uprev 2.20151208 -> 2.20161023
 refpolicy-minimum: update patch file

.../ftp-add-ftpd_t-to-mlsfilewrite.patch | 0
.../poky-fc-clock.patch  | 0
.../poky-fc-corecommands.patch   | 0
.../poky-fc-dmesg.patch  | 0
.../poky-fc-fix-bind.patch   | 0
.../poky-fc-fix-real-path_login.patch| 0
.../poky-fc-fix-real-path_resolv.conf.patch  | 0
.../poky-fc-fix-real-path_shadow.patch   | 0
.../poky-fc-fix-real-path_su.patch   | 0
.../poky-fc-fstools.patch| 0
.../poky-fc-ftpwho-dir.patch | 0
.../poky-fc-iptables.patch   | 0
.../poky-fc-mta.patch| 0
.../poky-fc-netutils.patch   | 0
.../poky-fc-nscd.patch   | 0
.../poky-fc-rpm.patch| 0
.../poky-fc-screen.patch | 0
.../poky-fc-ssh.patch| 0
.../poky-fc-su.patch | 0
.../poky-fc-subs_dist.patch  | 0
.../poky-fc-sysnetwork.patch | 0
.../poky-fc-udevd.patch  | 0
.../poky-fc-update-alternatives_hostname.patch   | 0
.../poky-fc-update-alternatives_sysklogd.patch   | 0
.../poky-fc-update-alternatives_sysvinit.patch   | 0
.../poky-policy-add-rules-for-bsdpty_device_t.patch  | 0
.../poky-policy-add-rules-for-syslogd_t-symlink.patch| 0
.../poky-policy-add-rules-for-tmp-symlink.patch  | 0
.../poky-policy-add-rules-for-var-cache-symlink.patch| 0
.../poky-policy-add-rules-for-var-log-symlink-apache.patch   | 0
...ky-policy-add-rules-for-var-log-symlink-audisp_remote_t.patch | 0
.../poky-policy-add-rules-for-var-log-symlink.patch  | 0
.../poky-policy-add-syslogd_t-to-trusted-object.patch| 0
.../poky-policy-allow-nfsd-to-exec-shell-commands.patch  | 0
.../poky-policy-allow-setfiles_t-to-read-symlinks.patch  | 0
.../poky-policy-allow-sysadm-to-run-rpcinfo.patch| 0
.../poky-policy-don-t-audit-tty_device_t.patch   | 0
.../poky-policy-fix-dmesg-to-use-dev-kmsg.patch  | 0
.../poky-policy-fix-new-SELINUXMNT-in-sys.patch  | 0
.../poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch  | 0
.../poky-policy-fix-setfiles-statvfs-get-file-count.patch| 0
.../poky-policy-fix-seutils-manage-config-files.patch| 0
.../refpolicy-update-for_systemd.patch   | 0
.../{refpolicy-mcs_2.20151208.bb => refpolicy-mcs_2.20161023.bb} | 0
...07-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch | 9 ++---
...icy-minimum_2.20151208.bb => refpolicy-minimum_2.20161023.bb} | 0
.../{refpolicy-mls_2.20151208.bb => refpolicy-mls_2.20161023.bb} | 0
...y-standard_2.20151208.bb => refpolicy-standard_2.20161023.bb} | 0
...y-targeted_2.20151208.bb => refpolicy-targeted_2.20161023.bb} | 0
.../{refpolicy_2.20151208.inc => refpolicy_2.20161023.inc}

Re: [yocto] [OE-core] OpenEmbedded Developers Meeting in Portland before ELC

2017-01-11 Thread Jeff Osier-Mixon 
That is an excellent question. The main issue is that the room usually
contains 20-25 people who are spread too far apart for many solutions to
hear effectively. This is compounded by normally not having any access to
the room until the morning of the event, so it is always a mad scramble.

This year I am focusing on using a regular conference phone rather than a
fancy solution, so there will be no video but hopefully there will be good
audio. I wish I had a permanent solution, but the room is completely
different at every event. I will keep working on it.

Stay tuned for dialup info (no, it won't be google hangout).

On Wed, Jan 11, 2017 at 5:47 PM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> On Mon, 09 Jan 2017 16:04:57 Philip Balister wrote:
> > As we do around each Embedded Linux Conference, OpenEmbedded will host a
> > developer meeting to discuss the state of OpenEmbedded and what efforts
> > we should focus on over the next six months or so.
> >
> > All developers and users are welcome to attend. We like to hear feedback
> > from a variety of people over what works, doesn't work, and is useful to
> > people using OpenEmbedded for all sort of applications.
> >
> > The meeting will be held Monday, Feb 20 at a location we can almost
> > announce. Based on prior years, the meeting will run from 9AM to 5PM.
> >
> > If you are going to attend add your name to:
> >
> > http://openembedded.org/wiki/OEDAM_2017
> >
> > Also, go ahead and add ideas for the agenda. We'll organize them better
> > just before the actual meeting.
>
> So it's great that this is happening, but unfortunately I'm not going to be
> able to make it to this one, and I suspect there will be many others who
> would
> like to participate but can't be present in person. In previous meetings we
> have really struggled with practical means for remote participation. I
> don't
> expect effective real-time two-way communication, but last time the audio
> was
> so poor I wasn't even able to hear what was being said.
>
> Is there a chance that given advance notice we will be able to set
> something
> up that could improve this?
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
Jeff Osier-Mixon - Open Source Community Engineer, Intel Corporation
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OpenEmbedded Developers Meeting in Portland before ELC

2017-01-11 Thread Paul Eggleton 
On Mon, 09 Jan 2017 16:04:57 Philip Balister wrote:
> As we do around each Embedded Linux Conference, OpenEmbedded will host a
> developer meeting to discuss the state of OpenEmbedded and what efforts
> we should focus on over the next six months or so.
> 
> All developers and users are welcome to attend. We like to hear feedback
> from a variety of people over what works, doesn't work, and is useful to
> people using OpenEmbedded for all sort of applications.
> 
> The meeting will be held Monday, Feb 20 at a location we can almost
> announce. Based on prior years, the meeting will run from 9AM to 5PM.
> 
> If you are going to attend add your name to:
> 
> http://openembedded.org/wiki/OEDAM_2017
> 
> Also, go ahead and add ideas for the agenda. We'll organize them better
> just before the actual meeting.

So it's great that this is happening, but unfortunately I'm not going to be 
able to make it to this one, and I suspect there will be many others who would 
like to participate but can't be present in person. In previous meetings we 
have really struggled with practical means for remote participation. I don't 
expect effective real-time two-way communication, but last time the audio was 
so poor I wasn't even able to hear what was being said.

Is there a chance that given advance notice we will be able to set something 
up that could improve this?

Cheers,
Paul

-- 

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

Re: [yocto] OpenEmbedded Developers Meeting in Portland before ELC

2017-01-11 Thread Jeff Osier-Mixon 
Hi Sandeep - yes, there is a DevDay planned for Friday Feb 24, after ELC.
Details and registration links are here:

https://www.yoctoproject.org/devday

On Wed, Jan 11, 2017 at 4:43 PM, Sandeep G.R  wrote:

> Hi Philip,
>
> Is Yocto developer day planned during ELC-2017 Portland, USA. Can you
> share the registration details if any?
>
> On Mon, Jan 9, 2017 at 2:04 PM, Philip Balister 
> wrote:
>
>> As we do around each Embedded Linux Conference, OpenEmbedded will host a
>> developer meeting to discuss the state of OpenEmbedded and what efforts
>> we should focus on over the next six months or so.
>>
>> All developers and users are welcome to attend. We like to hear feedback
>> from a variety of people over what works, doesn't work, and is useful to
>> people using OpenEmbedded for all sort of applications.
>>
>> The meeting will be held Monday, Feb 20 at a location we can almost
>> announce. Based on prior years, the meeting will run from 9AM to 5PM.
>>
>> If you are going to attend add your name to:
>>
>> http://openembedded.org/wiki/OEDAM_2017
>>
>> Also, go ahead and add ideas for the agenda. We'll organize them better
>> just before the actual meeting.
>>
>> See you all in Portland,
>>
>> Philip
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
> --
> *Thanks & Regards,*
> *Sandeep G R*
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 
Jeff Osier-Mixon - Open Source Community Engineer, Intel Corporation
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OpenEmbedded Developers Meeting in Portland before ELC

2017-01-11 Thread Sandeep G.R 
Hi Philip,

Is Yocto developer day planned during ELC-2017 Portland, USA. Can you share
the registration details if any?

On Mon, Jan 9, 2017 at 2:04 PM, Philip Balister  wrote:

> As we do around each Embedded Linux Conference, OpenEmbedded will host a
> developer meeting to discuss the state of OpenEmbedded and what efforts
> we should focus on over the next six months or so.
>
> All developers and users are welcome to attend. We like to hear feedback
> from a variety of people over what works, doesn't work, and is useful to
> people using OpenEmbedded for all sort of applications.
>
> The meeting will be held Monday, Feb 20 at a location we can almost
> announce. Based on prior years, the meeting will run from 9AM to 5PM.
>
> If you are going to attend add your name to:
>
> http://openembedded.org/wiki/OEDAM_2017
>
> Also, go ahead and add ideas for the agenda. We'll organize them better
> just before the actual meeting.
>
> See you all in Portland,
>
> Philip
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
*Thanks & Regards,*
*Sandeep G R*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] opkg.conf in sdk and custom URIs

2017-01-11 Thread Oleksy, Adam (Nokia - PL/Wroclaw) 
Hi all,
I've found that SDK produced by recipe meta-toolchain contains opkg.conf file 
with paths to the tmp/deploy/ipk/ directories.
In our company all the ipk files are also stored on the http server. I've 
prepared recipe which produce our flavor of the opkg.conf (opkg_http.conf), 
which is installed in the SDK, and alias for the opkg command to use this 
configuration file. I don't know whether this approach is correct. Maybe there 
is a better way to do it, e.g. configure yocto to change the content of the 
opkg.conf produced by meta-toolchain?
I've tried following variables: PACKAGE_FEED_ARCHS, PACKAGE_FEED_BASE_PATHS, 
PACKAGE_FEED_URIS, but it seems they are for opkg configuration for the target 
(not for sdk). Do you have any advices?
Thanks
 
.
 Best Regards,
 Adam Oleksy
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [[PATCH][layerindex]] layerindex: Update tinfoil to call shutdown method

2017-01-11 Thread Paul Eggleton 
On Wed, 11 Jan 2017 08:42:46 Aníbal Limón wrote:
> On 01/11/2017 02:59 AM, Paul Eggleton wrote:
> > On Thu, 05 Jan 2017 15:21:36 Aníbal Limón wrote:
> >> The new client/server API of tinfoil requires explicit call of
> >> shutdown method to send the event for finalize cooker process.
> >> 
> >> Also in update_layer remove the databuilder and cache instance
> >> now isn't needed.
> > 
> > This patch didn't apply against master - the databuilder piece does not
> > appear to be there.
> 
> Great may be was my own changes against RRS,
> 
> Only a comment if your layerindex scripts don't call shutdown the update
> script seems blocked because never arrives the event.

On the paule/django18 branch the update_layer.py script already calls 
shutdown(), and your patch takes care of the rest.

However this seems like a bug to me - if the client neglects to call 
shutdown() it would be nice if it didn't break things. Earlier I did use a 
destructor within the Tinfoil class to call shutdown() if it hadn't already 
been called, but I don't think that's reliable.

Cheers,
Paul

-- 

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

[yocto] [meta-mingw] Morty branch?

2017-01-11 Thread Mark Hatle 
I don't see any specific Morty branch available for meta-mingw.  Also many of
the patches that were in progress have not been integrated to the master branch
either.

I've posted the Wind River version of meta-mingw for use with Morty based
products to:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/

git://git.yoctoproject.org/meta-mingw-contrib

The 'mgh/morty' branch.

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

Re: [yocto] how does one stay on top of YP security alerts?

2017-01-11 Thread Mark Hatle 
On 1/11/17 8:49 AM, Philip Balister wrote:
> The question of security comes up at every OpenEmbedded developer
> meeting. Clearly, the companies building products with OpenEmbedded care
> about security.
> 
> The problem following the CVE's direct is you need to do analysis to
> determine if a specific release has the vulnerability.
> 
> We do have guidelines for marking CVE's addressed by commits, to help
> people interested in developing tools to show what CVE's are addressed
> in the meta data.
> 
> One suggestion made is to setup some form of git hook to email commits
> with CVE tags to the security list. We are very interested in
> encouraging people who care about security to use the security mailing
> list to improve overall security of distributions (like Poky) built with
> OpenEmbedded.

We started looking into having a git hook that would email the list whenever a
commit (with the CVE tag in it) was present, but with holidays (and other work
items I had).. this of course dropped lower in the priority list.

I do think this is the only reasonable way to do this.  Use an individual
branch's commit information to discover what is fixed.

If it's not listed as fixed, it's the users responsibility to understand if they
are vulnerable, deal with the vulnerability and (hopefully) send the patch to
the mailing lists so others can benefit from it.

(Speaking as a commercial OSV for a second)  The latest step of triage, fix and
send -- as well as announcing to customers and documenting things that are NOT
vulnerable are all services we provide.  I would expect any commercial OSV to
provide a similar service for their customers.  This is certainly a 'value-add'
that we do above and beyond the open source community.

This really is an 'above and beyond' request for the community.  The community
only cares about what HAS been fixed and the in-progress development release.
Anything beyond that is best effort, and the Yocto Project compliance guidelines
(and related process, encouraging contributions) helps keep commercial OSVs (who
do this work anyway) involved with keeping the community up to date.

--Mark

> Philip
> 
> On 01/10/2017 05:37 AM, Bent Bisballe Nyeng wrote:
>> On 01/10/2017 11:29 AM, Burton, Ross wrote:
>>
>> On 10 January 2017 at 10:01, Bent Bisballe Nyeng 
>> > wrote:
>> So /is/ the yocto-security mailinglist considered "dead"? Or has there
>> simply not been any security issues for a while?
>>
>> IIRC, yocto-security was more to discuss security issues, not an 
>> announcement of security related fixes.  If you care about security then 
>> you'll want notice for more than just what is in oe-core, so I suggest 
>> monitoring the CVE announcements directly.
>>
>> Ross
>>
>> I found the list initially through this page: 
>> https://wiki.yoctoproject.org/wiki/Security where it is described as the 
>> security [at] yoctoprojct [dot] org being the discussion list and the yocto 
>> [dash] security [at] yoctoproject[dot] org being the security announcement 
>> list.
>>
>> If the yocto [dash] security [at] yoctoproject[dot] org is in fact no longer 
>> active I think it is important that the wiki page is changed to reflect that 
>> to prevent potential dangerous misunderstandings in the future.
>>
>> Kind regards
>> Bent Bisballe Nyeng
>>
>>
>>

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

[yocto] [patchwork][PATCH] patchwork/bin/parsemail: Improve new patch filtering

2017-01-11 Thread Jose Lamego 
From: Jose Lamego 

Patchwork may incorrectly identify emails containing patch-like content or
that are replies/forwards from a previous message as patches, thus wrongly
creating a new series revision.
This change makes "[PATCH" prefix in subject mandatory for emails to be
considered as possible new patches, and makes any email with a subject
starting with any character other than a square bracket ("[") to be handled
as a possible comment to an existing patch.

[YOCTO #10764]
[YOCTO #10877]

Signed-off-by: Jose Lamego 
---

Notes:
v2 renamed to reflect that the subject filtering now includes ruling-out 
emails with a Subject header not starting with the expected square bracket

 patchwork/bin/parsemail.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/patchwork/bin/parsemail.py b/patchwork/bin/parsemail.py
index 1c2c774..94c7669 100755
--- a/patchwork/bin/parsemail.py
+++ b/patchwork/bin/parsemail.py
@@ -399,7 +399,8 @@ def find_content(project, mail):
 refs = build_references_list(mail)
 is_root = refs == []
 is_cover_letter = is_root and x == 0
-is_patch = patchbuf is not None
+patch_prefix = re.match('(\s*\[[^]]*\]\s*)*\[\s*PATCH', 
mail.get('Subject'))
+is_patch = patchbuf is not None and patch_prefix
 
 drop_patch = not is_attachment and \
 project.git_send_email_only and not is_git_send_email(mail)
-- 
1.9.1

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

Re: [yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT variables not availables ?

2017-01-11 Thread Khem Raj 
STAGING_DIR_HOST and STAGING_DIR_NATIVE are OE variables that can be
used in recipes to point to target and build host sysroots
respectively.

On Tue, Jan 10, 2017 at 11:22 PM, Karim ATIKI  wrote:
> Khem,
>
>
> Ok.
>
> How are they specified using Yocto build system ?
>
> Is there any doc link ?
>
>
>
> K.
>
>
> 
> De : Khem Raj 
> Envoyé : mardi 10 janvier 2017 20:39
> À : Karim ATIKI; yocto
> Objet : Re: [yocto] [bitbake] OECORE_TARGET_SYSROOT and
> OECORE_NATIVE_SYSROOT variables not availables ?
>
> These are specified differently when using the Yocto build system you should
> not be using these variables in your makefiles
> On Tue, Jan 10, 2017 at 8:11 AM Karim ATIKI  wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>>
>>
>>
>>
>>
>>
>>
>> I'm using generated Poky SDK to cross-compile our program source-codes,
>> which works fine.
>>
>>
>>
>>
>>
>>
>>
>>
>> Now I wish to integrate the build of the project into Yocto recipes using
>> our makefiles.
>>
>>
>>
>>
>>
>>
>>
>>
>> However, some custom parameters in the makefiles are using the variables
>> OECORE_TARGET_SYSROOT  and OECORE_NATIVE_SYSROOT to manage paths.
>>
>>
>>
>>
>> But it appears that these 2 variables do not exists when the makefiles are
>> called in a do_compile() function of a recipe.
>>
>>
>>
>>
>>
>>
>>
>>
>> Is it normal ? Did I did something wrong ?
>>
>>
>>
>> Should my recipe inherit something specific?
>>
>>
>>
>>
>>
>>
>>
>>
>> Or should I "source" my
>> "environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi" from the SDK into
>> my recipe file ? (=> not portable)
>>
>>
>>
>>
>>
>>
>>
>>
>> Thanks.
>>
>>
>>
>>
>>
>>
>>
>>
>> Z.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> ___
>>
>> 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] Failure Inheriting rpm_sign

2017-01-11 Thread Khem Raj 
On Wed, Jan 11, 2017 at 4:33 AM, Chris Trobridge
 wrote:
> On Mon, 2017-01-09 at 10:47 -0800, Khem Raj wrote:
>> On Fri, Jan 6, 2017 at 3:52 AM, Chris Trobridge
>>  wrote:
>> > I am getting "Exception: OSError: [Errno 7] Argument list too long"
>> > for sign_rpm in the do_package_write_rpm tasks for the
>> > linux-yocto and glibc-locale recipes.
>> >
>> > This is building core-image-minimal (and also my own image) with
>> > morty (5aa481d) on Fedora 25.
>> >
>> > I have enabled the rpm signing with:
>> >
>> > INHERIT += " sign_rpm"
>> > RPM_GPG_NAME = "{name}"
>> > RPM_GPG_PASSPHRASE = "{passphrase}"
>> > IMAGE_INSTALL_append = " signing-keys-rpm"
>> >
>> > The error message makes some sense in as much as these recipes
>> > produce a lot of packages (for example, glibc-locale produces 1791
>> > packages) and the command line in the log is pretty big, although
>> > reading around I didn't find a consensus on what the max command
>> > line should be.
>> >
>> > The code to sign rpms is in meta/lib/oe/gpg_sign.py
>> > b/meta/lib/oe/gpg_sign.py and it builds up one command line with
>> > all the packages.
>> >
>> > I changed the code (patch appended) to sign each rpm in a separate
>> > command and the build completed successfully.  The signing
>> > operations take a large amount of time so I think this might be a
>> > reasonable change but you may have other concerns.
>>
>> This certainly is useful, perhaps the signing bits can be moved to
>> individual
>> recipe packaging tasks that way it may be parallelized a bit
>>
>
> Thanks Raj,
>
> Something needs to be done as, unless I've messed up somewhere, you
> cannot build even core-image-minimal with rpm signing enabled so the
> sign_rpm class is effectively broken.

Its possible. I personally dont use rpm package management system, so
dont have first hand usecase here. may be you can open a bug as well


>
> The change I made works, but it's true is less efficient than signing
> rpms individually.  The expense of the signature generation meant it
> wasn't inefficient to sign each package in a recipe with a separate
> command.

existing logic must have worked at some point of time. It just is that
some bug has creeped in over period of time, may be due to it being
a less tested combination

>
> However, looking in package_rpm.bbclass, the end of do_package_rpm()
> has:
>
> if d.getVar('RPM_SIGN_PACKAGES', True) == '1':
> bb.build.exec_func("sign_rpm", d)
>
> So, to avoid confusion, all the rpms in one recipe are packaged in
> task, and then that task calls the function  sign all the packages.  I
> don't know if there's a way for do_package_rpm() to spawn tasks to sign
> each package individually.

I think it could be made so that all rpms coming out of a given recipe are
signed together

>
> I also found I needed 'IMAGE_INSTALL_append = " signing-keys-rpm"'
> local.conf, to deploy the public key but in sign_rpms.bbclass there is:
>
> do_package_index[depends] += "signing-keys:do_deploy"
> do_rootfs[depends] += "signing-keys:do_populate_sysroot"
>
> It may be this isn't quite what is required.

Perhaps turning this into a distro feature is a better option.

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

Re: [yocto] kernel config fragments not applied

2017-01-11 Thread Schmitt, Richard 
I think I have an apology to make.

My issue was that the config fragment I used (overlayfs.cfg) was:
CONFIG_OVERLAY_FS = yes

Note the spaces around the = sign.  With spaces, the setting is ignored.  When 
I changed the config fragment to:
CONFIG_OVERLAY_FS=yes
(without spaces), the setting took.

This was difficult to debug because there is no indication anywhere that the 
config fragment was bad.  There's not even notification anywhere that the 
config fragment tried to be applied.  So I assumed it wasn't even getting 
attempted.

Sorry for taking your time.  But thanks a lot for helping.  The fact that you 
had it working made me look even closer.

Rich

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Sent: Tuesday, January 10, 2017 5:36 PM
To: Schmitt, Richard ; yocto@yoctoproject.org
Subject: Re: [yocto] kernel config fragments not applied

On 2017-01-10 4:27 PM, Bruce Ashfield wrote:
> On 2017-01-10 4:20 PM, Bruce Ashfield wrote:
>> On 2017-01-10 4:13 PM, Schmitt, Richard wrote:
>>>
>>>
>>> -Original Message-
>>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>>> Sent: Tuesday, January 10, 2017 2:58 PM
>>> To: Schmitt, Richard ; 
>>> yocto@yoctoproject.org
>>> Subject: Re: [yocto] kernel config fragments not applied
>>>
>>> On 2017-01-10 1:05 PM, Schmitt, Richard wrote:
> I am having a heck of a hard time getting a minor kernel config 
> fragment applied.
>
>
>
> In order to minimize all variables, I am simply trying to build 
> linux-yocto for a qemux86 MACHINE target.
>
>
>

 What release ? Everything is working here, but I can switch to 
 whatever release you are using and run the test there (I'm using 
 master).
>>>
>>> I'm using krogoth.  I'll try a build based on master and see if it's 
>>> release specific.
>>
>> Thanks. I'm also spinning up a krogoth build .. you never know if 
>> something crept in. krogoth is before my audit code was visible, so 
>> hints as to why it failed likely aren't visible.
>
> Well I'll be  different behaviour with krogoth. I just updated it 
> and some patches came in from what I had been using before. It could 
> be something that merged recently.
>
> Anyway, leave this with me. I'll debug it tonight and spin a fix.

I take that back.

My first build was tainted with old sstate and didn't actually do anything. Now 
that I'm building with a clean slate on krogoth, I can create a local layer, 
add a linux-yocto_4.4.bbappend and add a overlay.cfg to enable CONFIG_OVERLAYFS.

Is it possible that you could tar up your test layer and send it with me, so I 
can try it directly ?

Bruce

>
> Bruce
>
>
>>
>> Bruce
>>
>>>
 Bruce
>>>
> There had been some discussion on the mailing list previously that 
> suggested making sure linux-yocto.inc was included within the recipes.
> The ones being used are standard poky recipes and they do include 
> the linux-yocto.inc file.
>
> My configuration is very simple.  I have my own layer and 
> linux-yocto
> bbappend:
>
> meta-mylayer/recipes-kernel/linux/linux-yocto_4.4.bbappend
>
> Whose contents are:
>
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> SRC_URI += " \
> file://overlayfs.cfg \
> "
>
> With the config fragment in:
>
> meta-mylayer/recipes-kernel/linux/linux-yocto/overlayfs.cfg
>
> whose contents is:
>
> CONFIG_OVERLAY_FS=y
>
> If I do a "bitbake linux-yocto" I would expect it to generate a 
> config file that includes CONFIG_OVERLAY_FS=y and a kernel that 
> includes this filesystem.  I don't.
>
> My layer is parsed correctly and the bbappend is found and parsed.  
> I know this because in the tmp directory:
>
> tmp/work/qemux86-poky-linux/linux-yocto/4.4.26+gitAUTOINC+3030330b
> 06_c
> a6a08bd7f-r0/
>
> the file overlayfs.cfg exists.
>
> Searching the log files, the only one that references this file 
> though is log.do_unpack.  I do not see any reference to it in
> log.do_kernel_configme or log.do_configure.I'm not sure how kernel
> fragments are applied, but looking through the classes and recipes 
> for linux-yocto in poky/meta, I do not see any code that would 
> apply kernel fragments.  So I'm not sure if I'm missing some piece.
>
> Searching through the files in poky/meta, I find meta-config.sh 
> only in recipes-core/uclibc and recipes-core/busybox.  That's why 
> I think I'm missing something.
>
> I'm using the krogoth branch of poky.
>
> What am I missing?
>
> Thanks,
> Rich
>>>
>>
>

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

Re: [yocto] kernel config fragments not applied

2017-01-11 Thread Bruce Ashfield 

On 2017-01-11 09:49 AM, Schmitt, Richard wrote:

I think I have an apology to make.



None needed!


My issue was that the config fragment I used (overlayfs.cfg) was:
CONFIG_OVERLAY_FS = yes

Note the spaces around the = sign.  With spaces, the setting is ignored.  When 
I changed the config fragment to:
CONFIG_OVERLAY_FS=yes
(without spaces), the setting took.

This was difficult to debug because there is no indication anywhere that the 
config fragment was bad.  There's not even notification anywhere that the 
config fragment tried to be applied.  So I assumed it wasn't even getting 
attempted.


That summary gives me an idea. I'll add that check to the config
fragment audit phase. We already detect other types of invalid
configs, and warn/error .. so this would be an easy one to check
and alert the user to the bad input.

Bruce



Sorry for taking your time.  But thanks a lot for helping.  The fact that you 
had it working made me look even closer.

Rich

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, January 10, 2017 5:36 PM
To: Schmitt, Richard ; yocto@yoctoproject.org
Subject: Re: [yocto] kernel config fragments not applied

On 2017-01-10 4:27 PM, Bruce Ashfield wrote:

On 2017-01-10 4:20 PM, Bruce Ashfield wrote:

On 2017-01-10 4:13 PM, Schmitt, Richard wrote:



-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, January 10, 2017 2:58 PM
To: Schmitt, Richard ;
yocto@yoctoproject.org
Subject: Re: [yocto] kernel config fragments not applied

On 2017-01-10 1:05 PM, Schmitt, Richard wrote:

I am having a heck of a hard time getting a minor kernel config
fragment applied.



In order to minimize all variables, I am simply trying to build
linux-yocto for a qemux86 MACHINE target.





What release ? Everything is working here, but I can switch to
whatever release you are using and run the test there (I'm using
master).


I'm using krogoth.  I'll try a build based on master and see if it's
release specific.


Thanks. I'm also spinning up a krogoth build .. you never know if
something crept in. krogoth is before my audit code was visible, so
hints as to why it failed likely aren't visible.


Well I'll be  different behaviour with krogoth. I just updated it
and some patches came in from what I had been using before. It could
be something that merged recently.

Anyway, leave this with me. I'll debug it tonight and spin a fix.


I take that back.

My first build was tainted with old sstate and didn't actually do anything. Now 
that I'm building with a clean slate on krogoth, I can create a local layer, 
add a linux-yocto_4.4.bbappend and add a overlay.cfg to enable CONFIG_OVERLAYFS.

Is it possible that you could tar up your test layer and send it with me, so I 
can try it directly ?

Bruce



Bruce




Bruce




Bruce



There had been some discussion on the mailing list previously that
suggested making sure linux-yocto.inc was included within the recipes.
The ones being used are standard poky recipes and they do include
the linux-yocto.inc file.

My configuration is very simple.  I have my own layer and
linux-yocto
bbappend:

meta-mylayer/recipes-kernel/linux/linux-yocto_4.4.bbappend

Whose contents are:


FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"


SRC_URI += " \
file://overlayfs.cfg \
"

With the config fragment in:

meta-mylayer/recipes-kernel/linux/linux-yocto/overlayfs.cfg

whose contents is:

CONFIG_OVERLAY_FS=y

If I do a "bitbake linux-yocto" I would expect it to generate a
config file that includes CONFIG_OVERLAY_FS=y and a kernel that
includes this filesystem.  I don't.

My layer is parsed correctly and the bbappend is found and parsed.
I know this because in the tmp directory:

tmp/work/qemux86-poky-linux/linux-yocto/4.4.26+gitAUTOINC+3030330b
06_c
a6a08bd7f-r0/

the file overlayfs.cfg exists.

Searching the log files, the only one that references this file
though is log.do_unpack.  I do not see any reference to it in
log.do_kernel_configme or log.do_configure.I'm not sure how kernel
fragments are applied, but looking through the classes and recipes
for linux-yocto in poky/meta, I do not see any code that would
apply kernel fragments.  So I'm not sure if I'm missing some piece.

Searching through the files in poky/meta, I find meta-config.sh
only in recipes-core/uclibc and recipes-core/busybox.  That's why
I think I'm missing something.

I'm using the krogoth branch of poky.

What am I missing?

Thanks,
Rich










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

Re: [yocto] how does one stay on top of YP security alerts?

2017-01-11 Thread Alexander Kanavin 

On 01/11/2017 04:49 PM, Philip Balister wrote:

The problem following the CVE's direct is you need to do analysis to
determine if a specific release has the vulnerability.

We do have guidelines for marking CVE's addressed by commits, to help
people interested in developing tools to show what CVE's are addressed
in the meta data.

>

One suggestion made is to setup some form of git hook to email commits
with CVE tags to the security list.


This is not going to work if a security issue is fixed by a version 
update without an intermediate backported patch (which often happens). 
And cve-check-tool is notorious for inaccuracies both ways.


There's simply no easy, working solution to this, the way I see it. In 
the master branch the best we can do is to stay close to upstream, for 
release branches the only thing that will really work is having real 
recipe maintainers who follow upstream development closely.


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

Re: [yocto] how does one stay on top of YP security alerts?

2017-01-11 Thread Philip Balister 
The question of security comes up at every OpenEmbedded developer
meeting. Clearly, the companies building products with OpenEmbedded care
about security.

The problem following the CVE's direct is you need to do analysis to
determine if a specific release has the vulnerability.

We do have guidelines for marking CVE's addressed by commits, to help
people interested in developing tools to show what CVE's are addressed
in the meta data.

One suggestion made is to setup some form of git hook to email commits
with CVE tags to the security list. We are very interested in
encouraging people who care about security to use the security mailing
list to improve overall security of distributions (like Poky) built with
OpenEmbedded.

Philip

On 01/10/2017 05:37 AM, Bent Bisballe Nyeng wrote:
> On 01/10/2017 11:29 AM, Burton, Ross wrote:
> 
> On 10 January 2017 at 10:01, Bent Bisballe Nyeng 
> > wrote:
> So /is/ the yocto-security mailinglist considered "dead"? Or has there
> simply not been any security issues for a while?
> 
> IIRC, yocto-security was more to discuss security issues, not an announcement 
> of security related fixes.  If you care about security then you'll want 
> notice for more than just what is in oe-core, so I suggest monitoring the CVE 
> announcements directly.
> 
> Ross
> 
> I found the list initially through this page: 
> https://wiki.yoctoproject.org/wiki/Security where it is described as the 
> security [at] yoctoprojct [dot] org being the discussion list and the yocto 
> [dash] security [at] yoctoproject[dot] org being the security announcement 
> list.
> 
> If the yocto [dash] security [at] yoctoproject[dot] org is in fact no longer 
> active I think it is important that the wiki page is changed to reflect that 
> to prevent potential dangerous misunderstandings in the future.
> 
> Kind regards
> Bent Bisballe Nyeng
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [[PATCH][layerindex]] layerindex: Update tinfoil to call shutdown method

2017-01-11 Thread Aníbal Limón 


On 01/11/2017 02:59 AM, Paul Eggleton wrote:
> Hi Aníbal,
> 
> On Thu, 05 Jan 2017 15:21:36 Aníbal Limón wrote:
>> The new client/server API of tinfoil requires explicit call of
>> shutdown method to send the event for finalize cooker process.
>>
>> Also in update_layer remove the databuilder and cache instance
>> now isn't needed.
> 
> This patch didn't apply against master - the databuilder piece does not 
> appear 
> to be there.

Great may be was my own changes against RRS,

Only a comment if your layerindex scripts don't call shutdown the update
script seems blocked because never arrives the event.

Cheers,
alimon
> 
> Since it was a simple patch, I've remade the changes (with most of your 
> commit 
> message) and pushed it to the paule/django18 branch that hopefully we'll be 
> moving over to soon.
> 
> Cheers,
> Paul
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023

2017-01-11 Thread Joe MacDonald 
[Re: [yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023] On 
17.01.11 (Wed 10:24) wenzong fan wrote:

> On 01/10/2017 10:25 PM, Joe MacDonald wrote:
> >[[yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023] On 
> >17.01.10 (Tue 00:54) wenzong@windriver.com wrote:
> >
> >>From: Wenzong Fan 
> >>
> >>Uprev refpolicy to 2.20161023 and fix build errors for refpolicy-minimum.
> >>
> >>The following changes since commit bae51859f0dbcdde9fd563d15128a6dbbb816801:
> >>
> >>  audit: upgrade 2.6.6 -> 2.7 (2017-01-09 08:59:55 -0500)
> >>
> >>are available in the git repository at:
> >>
> >>  git://git.pokylinux.org/poky-contrib wenzong/refpolicy-2.20161023
> >>  
> >> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/refpolicy-2.20161023
> >
> >As poky-contrib is full of unrelated stuff, it's not the right place to
> >be doing meta-selinux work AFAICT.  I'd rather you actually just
> >fork meta-selinux somewhere like github if you plan to send pull
> >requests.  Patches are fine, of course, they're even easier for me to
> >work with.
> 
> Oko< I didn't notice that before, I'll fork it on github for my pull
> requests later.

You don't have to, patches are always fine with me.  I'm just letting
you know that I won't be pulling anything from your poky-contrib
branches for meta-selinux since they're completely different repos.

Thanks Wenzong.
-J.

> 
> Thanks
> Wenzong
> 
> >
> >-J.
> >
> >>
> >>Wenzong Fan (2):
> >>  refpolicy: uprev 2.20151208 -> 2.20161023
> >>  refpolicy-minimum: update patch file
> >>
> >> .../ftp-add-ftpd_t-to-mlsfilewrite.patch | 0
> >> .../poky-fc-clock.patch  | 0
> >> .../poky-fc-corecommands.patch   | 0
> >> .../poky-fc-dmesg.patch  | 0
> >> .../poky-fc-fix-bind.patch   | 0
> >> .../poky-fc-fix-real-path_login.patch| 0
> >> .../poky-fc-fix-real-path_resolv.conf.patch  | 0
> >> .../poky-fc-fix-real-path_shadow.patch   | 0
> >> .../poky-fc-fix-real-path_su.patch   | 0
> >> .../poky-fc-fstools.patch| 0
> >> .../poky-fc-ftpwho-dir.patch | 0
> >> .../poky-fc-iptables.patch   | 0
> >> .../poky-fc-mta.patch| 0
> >> .../poky-fc-netutils.patch   | 0
> >> .../poky-fc-nscd.patch   | 0
> >> .../poky-fc-rpm.patch| 0
> >> .../poky-fc-screen.patch | 0
> >> .../poky-fc-ssh.patch| 0
> >> .../poky-fc-su.patch | 0
> >> .../poky-fc-subs_dist.patch  | 0
> >> .../poky-fc-sysnetwork.patch | 0
> >> .../poky-fc-udevd.patch  | 0
> >> .../poky-fc-update-alternatives_hostname.patch   | 0
> >> .../poky-fc-update-alternatives_sysklogd.patch   | 0
> >> .../poky-fc-update-alternatives_sysvinit.patch   | 0
> >> .../poky-policy-add-rules-for-bsdpty_device_t.patch  | 0
> >> .../poky-policy-add-rules-for-syslogd_t-symlink.patch| 0
> >> .../poky-policy-add-rules-for-tmp-symlink.patch  | 0
> >> .../poky-policy-add-rules-for-var-cache-symlink.patch| 0
> >> .../poky-policy-add-rules-for-var-log-symlink-apache.patch   | 0
> >> ...ky-policy-add-rules-for-var-log-symlink-audisp_remote_t.patch | 0
> >> .../poky-policy-add-rules-for-var-log-symlink.patch  | 0
> >> .../poky-policy-add-syslogd_t-to-trusted-object.patch| 0
> >> .../poky-policy-allow-nfsd-to-exec-shell-commands.patch  | 0
> >> .../poky-policy-allow-setfiles_t-to-read-symlinks.patch  | 0
> >> .../poky-policy-allow-sysadm-to-run-rpcinfo.patch| 0
> >> .../poky-policy-don-t-audit-tty_device_t.patch   | 0
> >> .../poky-policy-fix-dmesg-to-use-dev-kmsg.patch  | 0
> >> .../poky-policy-fix-new-SELINUXMNT-in-sys.patch  | 0
> >> .../poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch  | 0
> >> .../poky-policy-fix-setfiles-statvfs-get-file-count.patch| 0
> >> .../poky-policy-fix-seutils-manage-config-files.patch| 0
> >> .../refpolicy-update-for_systemd.patch   | 0
> >> .../{refpolicy-mcs_2.20151208.bb => refpolicy-mcs_2.20161023.bb} | 0
> >> ...07-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch | 9 
> >> ++---
> >> ...icy-minimum_2.20151208.bb =>

[linux-yocto] [PATCH] Fix crash bug when skl_probe fail

2017-01-11 Thread Guoqing Zhang 
The skl_free expects no display is powered on when called. The fix
makes sure the display is powered off before calling it

Signed-off-by: Guoqing Zhang 
---
 sound/soc/intel/skylake/skl.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index 55278b5..79ae13a 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -752,6 +752,14 @@ out_nhlt_free:
skl_nhlt_free(skl->nhlt);
 out_free:
skl->init_failed = 1;
+
+   if (IS_ENABLED(CONFIG_SND_SOC_HDAC_HDMI)) {
+   // make sure display is powered off before
+   // calling skl_free
+   if (bus->i915_power_refcount > 0)
+   snd_hdac_display_power(bus, false);
+   }
+
skl_free(ebus);
 
return err;
-- 
2.5.0

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

Re: [yocto] Failure Inheriting rpm_sign

2017-01-11 Thread Chris Trobridge 
On Mon, 2017-01-09 at 10:47 -0800, Khem Raj wrote:
> On Fri, Jan 6, 2017 at 3:52 AM, Chris Trobridge
>  wrote:
> > I am getting "Exception: OSError: [Errno 7] Argument list too long"
> > for sign_rpm in the do_package_write_rpm tasks for the
> > linux-yocto and glibc-locale recipes.
> > 
> > This is building core-image-minimal (and also my own image) with
> > morty (5aa481d) on Fedora 25.
> > 
> > I have enabled the rpm signing with:
> > 
> > INHERIT += " sign_rpm"
> > RPM_GPG_NAME = "{name}"
> > RPM_GPG_PASSPHRASE = "{passphrase}"
> > IMAGE_INSTALL_append = " signing-keys-rpm"
> > 
> > The error message makes some sense in as much as these recipes
> > produce a lot of packages (for example, glibc-locale produces 1791
> > packages) and the command line in the log is pretty big, although
> > reading around I didn't find a consensus on what the max command
> > line should be.
> > 
> > The code to sign rpms is in meta/lib/oe/gpg_sign.py
> > b/meta/lib/oe/gpg_sign.py and it builds up one command line with
> > all the packages.
> > 
> > I changed the code (patch appended) to sign each rpm in a separate
> > command and the build completed successfully.  The signing
> > operations take a large amount of time so I think this might be a
> > reasonable change but you may have other concerns.
> 
> This certainly is useful, perhaps the signing bits can be moved to
> individual
> recipe packaging tasks that way it may be parallelized a bit
> 

Thanks Raj,

Something needs to be done as, unless I've messed up somewhere, you
cannot build even core-image-minimal with rpm signing enabled so the
sign_rpm class is effectively broken.

The change I made works, but it's true is less efficient than signing
rpms individually.  The expense of the signature generation meant it
wasn't inefficient to sign each package in a recipe with a separate
command.

However, looking in package_rpm.bbclass, the end of do_package_rpm()
has:

if d.getVar('RPM_SIGN_PACKAGES', True) == '1':
bb.build.exec_func("sign_rpm", d)

So, to avoid confusion, all the rpms in one recipe are packaged in
task, and then that task calls the function  sign all the packages.  I
don't know if there's a way for do_package_rpm() to spawn tasks to sign
each package individually.

I also found I needed 'IMAGE_INSTALL_append = " signing-keys-rpm"'
local.conf, to deploy the public key but in sign_rpms.bbclass there is:

do_package_index[depends] += "signing-keys:do_deploy"
do_rootfs[depends] += "signing-keys:do_populate_sysroot"

It may be this isn't quite what is required.

Regards,
Chris

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

Re: [yocto] has support for MPC8315E-RDB been dropped?

2017-01-11 Thread Joshua Lock 
On Mon, 2017-01-09 at 10:17 +, Burton, Ross wrote:
> Nope, we're missing a tarball somewhere.  Can you file a bug?

Filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=10911
Joshua
> Ross
> On 6 January 2017 at 22:30, Robert P. J. Day 
> wrote:
> >   i notice that if you search for the powerpc BSP in the latest
> > 
> > release here:
> > 
> > 
> > 
> > https://www.yoctoproject.org/downloads/bsps?release=98%5B
> > %5D=22=
> > 
> > 
> > 
> > you get no match. i haven't been paying attention -- has yocto
> > dropped
> > 
> > that board as its powerpc reference board? is it being replaced by
> > a
> > 
> > newer powerpc system?
> > 
> > 
> > 
> > rday
> > 
> > 
> > 
> > --
> > 
> > 
> > 
> > ===
> > =
> > 
> > Robert P. J. Day                                 Ottawa, Ontario,
> > CANADA
> > 
> >                         http://crashcourse.ca
> > 
> > 
> > 
> > Twitter:                                       http://twitter.com/r
> > pjday
> > 
> > LinkedIn:                               http://ca.linkedin.com/in/r
> > pjday
> > 
> > ===
> > =
> > 
> > 
> > 
> > --
> > 
> > ___
> > 
> > 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] Adding to inittab based on image content

2017-01-11 Thread colin.helliwell 
Thanks Rudi, that's got it.

-Original Message-
From: Rudolf J Streif [mailto:rudolf.str...@gmail.com] 
Sent: 06 January 2017 17:18
To: yocto@yoctoproject.org; colin.helliw...@ln-systems.com
Subject: Re: [yocto] Adding to inittab based on image content

Hi Colin,

The correct way of doing this is a package postinstallation script that is
run by the package manager after the package containing your application is
installed on the target system.

You add to your recipe:

pkg_postinst_${PN}() {
#!/bin/sh
echo "whateveryouneed" >> ${D}/etc/inittab }

The build system will include this as the post install script into the
package in the correct form for the package manager you are using e.g. RPM,
DEB, IPK.

This will work when the build system installs your package into the system
root or when executed on the target.

You can also distinguish the two cases:

pkg_postinst_${PN}() {
#!/bin/sh
if [ x"$D" = "x" ] ; then
   # shell commands for target execution else
   # shell commands for build system execution fi }

In the case of target execution $D is not set.


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

Re: [yocto] [[PATCH][layerindex]] layerindex: Update tinfoil to call shutdown method

2017-01-11 Thread Paul Eggleton 
Hi Aníbal,

On Thu, 05 Jan 2017 15:21:36 Aníbal Limón wrote:
> The new client/server API of tinfoil requires explicit call of
> shutdown method to send the event for finalize cooker process.
> 
> Also in update_layer remove the databuilder and cache instance
> now isn't needed.

This patch didn't apply against master - the databuilder piece does not appear 
to be there.

Since it was a simple patch, I've remade the changes (with most of your commit 
message) and pushed it to the paule/django18 branch that hopefully we'll be 
moving over to soon.

Cheers,
Paul

-- 

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

Re: [yocto] how does one stay on top of YP security alerts?

2017-01-11 Thread Bent Bisballe Nyeng 
On 01/10/2017 09:53 PM, Paul Eggleton wrote:
> On Tue, 10 Jan 2017 10:37:48 Bent Bisballe Nyeng wrote:
>> I found the list initially through this page:
>> https://wiki.yoctoproject.org/wiki/Security where it is described as the
>> security [at] yoctoprojct [dot] org being the discussion list and the yocto
>> [dash] security [at] yoctoproject[dot] org being the security announcement
>> list.
> That's not what it says. What it does say is that yocto-security@ list is for 
> discussions about security patches, and security@ is for private notification 
> about security issues *to* several nominated individuals. There isn't an 
> announcement list I'm afraid.
>  
>> If the yocto [dash] security [at] yoctoproject[dot] org is in fact no longer
>> active I think it is important that the wiki page is changed to reflect
>> that to prevent potential dangerous misunderstandings in the future.
> I'm not sure how you came to the conclusions you did - do you have any 
> suggestions on rewording?
>
> I will say that the yocto-security@ list has been pretty quiet since it was 
> set up. Adding a few people on CC - are there any plans to make better use of 
> this list?
>
> Cheers,
> Paul
I can see now that I half read, half assumed what the page said...

The ideal solution in my opinion would be to actually turn the
yocto-security list into a security announcement list as this would make
it the perfect resource for monitoring security issues for shipped
products instead of having to make some kind of grep filter on the git logs.

Would this be an option? I think it would be of great benefit to the
yocto community if such a list existed.

Kind regards
Bent Bisballe Nyeng

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