[linux-yocto] [PATCH 1/1] features/security: add configs to harden protection

[Anuj Mittal]

Add a feature that enables/disables configurations that impact kernel
security with an aim of decreasing the attack surface.

Signed-off-by: Anuj Mittal 
---
 features/security/security.cfg | 48 ++
 features/security/security.scc |  4 +++
 2 files changed, 52 insertions(+)
 create mode 100644 features/security/security.cfg
 create mode 100644 features/security/security.scc

diff --git a/features/security/security.cfg b/features/security/security.cfg
new file mode 100644
index ..efcbe056
--- /dev/null
+++ b/features/security/security.cfg
@@ -0,0 +1,48 @@
+# Protect against ioctl buffer overflows
+CONFIG_HARDENED_USERCOPY=y
+
+# Check for memory copies that might overflow a structure in str*() and mem*()
+# functions both at build-time and run-time
+CONFIG_FORTIFY_SOURCE=y
+
+# Harden the slab free list with randomization
+CONFIG_SLAB_FREELIST_RANDOM=y
+CONFIG_SLAB_FREELIST_HARDENED=y
+
+# Stack Protector is for buffer overflow detection and hardening
+CONFIG_CC_STACKPROTECTOR=y
+# CONFIG_CC_STACKPROTECTOR_NONE is not set
+CONFIG_CC_STACKPROTECTOR_REGULAR=y
+
+# Perform extensive checks on reference counting
+CONFIG_REFCOUNT_FULL=y
+
+# Disable to ensure random heap placement to make exploits harder
+# CONFIG_COMPAT_BRK is not set
+
+# Disable; exposes kernel text image layout
+# CONFIG_PROC_KCORE is not set
+
+# Increases the low-level kernel attack surface. Disable it instead.
+# Removes the modify_ldt system call.
+CONFIG_EXPERT=y
+CONFIG_MODIFY_LDT_SYSCALL=n
+
+# Modern libc no longer needs a fixed-position mapping in userspace, remove it 
as a possible target.
+# CONFIG_LEGACY_VSYSCALL_EMULATE is not set
+CONFIG_LEGACY_VSYSCALL_NONE=y
+
+# Prior to v4.1, assists heap memory attacks; best to keep interface disabled.
+# CONFIG_INET_DIAG is not set
+
+# Do not allow direct physical memory access (enable only STRICT mode...)
+# CONFIG_DEVMEM is not set
+CONFIG_STRICT_DEVMEM=y
+CONFIG_IO_STRICT_DEVMEM=y
+
+# Perform additional validation of various commonly targeted structures
+CONFIG_SCHED_STACK_END_CHECK=y
+CONFIG_DEBUG_LIST=y
+CONFIG_DEBUG_SG=y
+CONFIG_DEBUG_NOTIFIERS=y
+CONFIG_DEBUG_CREDENTIALS=y
diff --git a/features/security/security.scc b/features/security/security.scc
new file mode 100644
index ..0864eb7d
--- /dev/null
+++ b/features/security/security.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "Enable/disable configurations that impact kernel 
security"
+define KFEATURE_COMPATIBILITY all
+
+kconf non-hardware security.cfg
-- 
2.17.1

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

[linux-yocto] [PATCH 0/1] Harden kernel configuration

[Anuj Mittal]

This change adds a feature to enable some of the kernel configs that
improve kernel self-protection/security. More details are available at
the kernel self-protection project page [1].

This is not being enabled by default and can be included using
KERNEL_FEATURES if required by a BSP. 

Can this be merged in master/4.14/4.15 please?

[1] 
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings

Anuj Mittal (1):
  features/security: add configs to harden protection

 features/security/security.cfg | 48 ++
 features/security/security.scc |  4 +++
 2 files changed, 52 insertions(+)
 create mode 100644 features/security/security.cfg
 create mode 100644 features/security/security.scc

-- 
2.17.1

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

Re: [yocto] [PATCH][meta-dpdk] dpdk-dev-libibverbs: fix do_fetch error

[Anuj Mittal]

On 08/14/2018 09:37 AM, Changqing Li wrote:
> 
> 
> On 08/13/2018 02:35 PM, Anuj Mittal wrote:
>> On 08/13/2018 01:22 PM, changqing...@windriver.com wrote:
>>> From: Changqing Li 
>>>
>>> original URI have been deleted(don't know why). I noticed there is
>>> an official libibverbs(https://git.kernel.org/pub/scm/libs/infiniband
>>> /libibverbs.git),
>> The deprecation notice seems to imply that rdma-core on github should be
>> used instead and that's what debian does too. Perhaps that should be
>> used instead?
>>
>> https://tracker.debian.org/pkg/rdma-core
> 
> About you mentioned "deprecation notice " ,  I don't find it on original 
> github of Mellanox
> can you send me a link of this notice? Thanks.

https://git.kernel.org/pub/scm/libs/infiniband/libibverbs.git/commit/?id=1a6ab7f4c4aa048e8cf0c6cbed5935181f660bd8

And, this:

https://www.openfabrics.org/downloads/verbs/README.html

> 
> besides,  from https://tracker.debian.org/pkg/rdma-core,  I  can get the 
> repo is here
> https://github.com/linux-rdma/rdma-core,  but it is not only 
> libibverbs,  it is source
> include some other package,  I think it is not proper here.
> 

If you take a look at older version of libibverbs there, you'd see the
code that we had. The later versions are pulling from rdma-core.

You don't need to install everything, just the things that are needed
for dpdk ...
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-dpdk] dpdk-dev-libibverbs: fix do_fetch error

[Changqing Li]

On 08/13/2018 02:35 PM, Anuj Mittal wrote:

On 08/13/2018 01:22 PM, changqing...@windriver.com wrote:

From: Changqing Li 

original URI have been deleted(don't know why). I noticed there is
an official libibverbs(https://git.kernel.org/pub/scm/libs/infiniband
/libibverbs.git),

The deprecation notice seems to imply that rdma-core on github should be
used instead and that's what debian does too. Perhaps that should be
used instead?

https://tracker.debian.org/pkg/rdma-core


About you mentioned "deprecation notice " ,  I don't find it on original 
github of Mellanox

can you send me a link of this notice? Thanks.

besides,  from https://tracker.debian.org/pkg/rdma-core,  I  can get the 
repo is here
https://github.com/linux-rdma/rdma-core,  but it is not only 
libibverbs,  it is source

include some other package,  I think it is not proper here.

//Sandy

but there are big differences with original one.
I don't have condition to test this now, I can only go as far as builds
OK. so I select use tar.gz on yocto to make sure fetch can success and
original function not be affected.

I also noticed a project seems like Mellanox libibverbs,
https://github.com/gpudirect/libibverbs, but it don't have any
official release now.

Hope in the future, we can switch to the offcial libibverbs, or
the new Mellanox libibverbs. but now, we use this yocto tar.gz
as a workaround to make it at least work now.




--
BRs

Sandy(Li Changqing)
+861084778653

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

Re: [yocto] bbappend and placing a file into /tmp on the target

[Khem Raj]

May be look into VOLATILE_BINDS

On Mon, Aug 13, 2018 at 1:12 PM Bishop, Mark (STRT) <
mbis...@smithsinterconnectinc.com> wrote:

> I am trying to expand an existing package (base-passwd) and having it
> place /etc/passwd into /tmp/
>
>
>
> I’m failing pretty miserably and am looking for some hints/tips.
>
>
>
> *Mark Bishop*
>
> *Sr. Firmware/Software Engineer – Microwave Subsystems*
>
>
>
> [image: cid:image001.png@01D281ED.A45F0A90]
>
> 4726 Eisenhower Blvd.
>
> Tampa, FL 33634
>
> USA
>
>
>
> T  +1 813 901 7293
>
> *mbis...@smithsinterconnectinc.com *
>
> *smithsinterconnect.com* 
>
> *TRAK MICROWAVE IS NOW SMITHS INTERCONNECT!*
>
>
>
>
>
> This e-mail contains proprietary information some or all of which may be
> legally privileged. It is intended for the recipient only. If an addressing
> or transmission error has misdirected this e-mail, please notify the
> authority by replying to this e-mail. If you are not the intended recipient
> you must not use, disclose, distribute, copy, print, or rely on this
> e-mail. In addition, information contained in or attached to this e-mail
> may be subject to either 22 C.F.R. Parts 120?130, or 15 C.F.R. Parts
> 730-774. These regulations prohibit the release or disclosure of certain
> information contained herein to anyone who is not a U.S. citizen or
> permanent resident alien, without a license first having been issued.
> Failure to observe such requirements is a violation of U.S. law that
> carries serious penalties.   ­­
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] bbappend and placing a file into /tmp on the target

[Bishop, Mark (STRT)]

I am trying to expand an existing package (base-passwd) and having it place 
/etc/passwd into /tmp/

I'm failing pretty miserably and am looking for some hints/tips.

Mark Bishop
Sr. Firmware/Software Engineer - Microwave Subsystems

[cid:image001.png@01D281ED.A45F0A90]

4726 Eisenhower Blvd.
Tampa, FL 33634
USA


T  +1 813 901 7293

mbis...@smithsinterconnectinc.com

smithsinterconnect.com

TRAK MICROWAVE IS NOW SMITHS INTERCONNECT!





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

[yocto] [meta-security][PATCH] libseccomp: Drop RDEPENDS on bash

[Alex Kiernan]

Commit ada3eee ("libseccomp: fix rdepends") added RDEPENDS on bash, but
this is no longer needed, so drop it.

Signed-off-by: Alex Kiernan 
---

 recipes-security/libseccomp/libseccomp_2.3.3.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/recipes-security/libseccomp/libseccomp_2.3.3.bb 
b/recipes-security/libseccomp/libseccomp_2.3.3.bb
index 8d58163..0a8a679 100644
--- a/recipes-security/libseccomp/libseccomp_2.3.3.bb
+++ b/recipes-security/libseccomp/libseccomp_2.3.3.bb
@@ -38,5 +38,4 @@ do_install_ptest() {
 FILES_${PN} = "${bindir} ${libdir}/${PN}.so*"
 FILES_${PN}-dbg += "${libdir}/${PN}/tests/.debug/* 
${libdir}/${PN}/tools/.debug"
 
-RDEPENDS_${PN} = "bash"
 RDEPENDS_${PN}-ptest = "bash"
-- 
2.7.4

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

Re: [linux-yocto] v4.12.x - stable updates comprising v4.12.28

[akuster808]

On 08/13/2018 08:00 AM, Paul Gortmaker wrote:
> Bruce, Yocto kernel folks:
>
> Here is another 4.12.x stable update "extension" primarily created for
> the Yocto project, continuing on top of the previous v4.12.27 kernel.
>
> Hopefully people using 4.12.x have their plans well underway to move to
> a newer kernel, as I have been indicating for several releases now that
> my maintenance work on 4.12.x is coming to a close.  
Thank you for all your time and effort in maintaining this branch.

> There will probably
> be one more release in roughly two weeks, assuming we don't encounter
> any high profile CVE issues in the interim.
You included the fix for "CVE-2018-5390 kernel: TCP segments with random
offsets allow a remote denial of service (SegmentSmack)"

thanks,
Armin
>
> There are just over 80 commits here, based on commits chosen from what
> was used in existing 4.14.x stable releases.
>
> I've put this 4.12.x queue through the usual testing that I figured made
> sense, which is in line with that listed explicitly in previous release
> announcements.
>
> I did the signed tag just as per the previously released 4.12.x versions.
>
> Please find a signed v4.12.28 tag using this key:
>
> http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
>
> in the repo in the kernel.org directory here:
>
>https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
>git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git
>
> for merge to standard/base in linux-yocto-4.12 and then out from there
> into the other base and BSP branches.
>
> For those who are interested, the evolution of the commits is here:
>
>https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/
>
> This repo isn't needed for anything; it just exists for transparency and
> so people can see the evolution of the raw commits that were originally
> selected to create this 4.12.x release.
>
> Paul.
> --

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

[yocto] Yocto Project Unassigned Bugs - Help Needed

[Jolley, Stephen K]

All,



The triage team meets weekly and does its best to handle the bugs reported into 
the bugzilla. The number of people attending that meeting has fallen, as have 
the number of people available to help fix bugs. One of the things we hear 
users report is they don't know how to help. We (the triage team) are therefore 
going to start reporting out the currently 315 unassigned bugs.



We're hoping people may be able to spare some time now and again to help out 
with these.



Bugs are split into two types, "true bugs" where things don't work as they 
should and "enhancements" which are features we'd want to add to the system.



There are also roughly three different "priority" classes right now, "2.6", 
"2.99" and "Future", the more pressing/urgent issues being in "2.6".



Please review this link and if a bug is something you would be able to help 
with either take ownership of the bug, or send me (stephen.k.jol...@intel.com) 
an e-mail with the bug number you would like and I will assign it to you 
(please make sure you have a bugzilla account).



The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_Bugs


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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

Re: [linux-yocto] [PATCH] scripts/kconfig: Fix menuconfig failure

[Bruce Ashfield]

Which kernel version(s) are you seeing this issue ? Just linux-yocto-dev ?

Bruce

On 08/11/2018 11:11 AM, He Zhe wrote:

The folloing porting lacks of change log and breaks menuconfig.
CROSS_CURSES_LIB or CROSS_CURSES_INC contains xxx"" which is
finially evaluated as "xxx""" in which < and > would be
considered as I/O redirection and cause the faliure below.

4ead19c77a5baaf44bfa6600b1be884e47c9d8f1
"menuconfig,mconf-cfg: Allow specification of ncurses location"

scripts/kconfig/.mconf-cfg: line 2: curses.h: No such file or directory
...
mconf.c:(.text+0x894): undefined reference to `stdscr'
...
scripts/Makefile.host:99: recipe for target 'scripts/kconfig/mconf' failed

This patch turns to use single quotes.

Signed-off-by: He Zhe 
---
  scripts/kconfig/mconf-cfg.sh | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh
index 557be6dc1abf..3bd1f9a363e6 100755
--- a/scripts/kconfig/mconf-cfg.sh
+++ b/scripts/kconfig/mconf-cfg.sh
@@ -5,9 +5,9 @@ PKG="ncursesw"
  PKG2="ncurses"
  
  if [ "$CROSS_CURSES_LIB" != "" ]; then

-   echo libs=\"$CROSS_CURSES_LIB\"
+   echo libs=\'$CROSS_CURSES_LIB\'
if [ x"$CROSS_CURSES_INC" != x ]; then
-   echo cflags=\"$CROSS_CURSES_INC\"
+   echo cflags=\'$CROSS_CURSES_INC\'
fi
exit 0
  fi



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

[yocto] Creating multiple filesystem images

[Amol Lad]

Hi,

Currently when we build say core-image-minimal, we get a root file system image 
(say ext4) after the build. However, I also need to create an ext4 image for 
/boot partition (which contains zImage and dtb). I do not want wic image. How I 
can do this? i.e. I want two ext4 images after build: one root file system and 
another with content of /boot folder. Please advise

Thanks in advance
Amol

The information in this email communication (inclusive of attachments) is 
confidential to 4RF Limited and the intended recipient(s). If you are not the 
intended recipient(s), please note that any use, disclosure, distribution or 
copying of this information or any part thereof is strictly prohibited and that 
the author accepts no liability for the consequences of any action taken on the 
basis of the information provided. If you have received this email in error, 
please notify the sender immediately by return email and then delete all 
instances of this email from your system. 4RF Limited will not accept 
responsibility for any consequences associated with the use of this email 
(including, but not limited to, damages sustained as a result of any viruses 
and/or any action or lack of action taken in reliance on it).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.28

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.27 kernel.

Hopefully people using 4.12.x have their plans well underway to move to
a newer kernel, as I have been indicating for several releases now that
my maintenance work on 4.12.x is coming to a close.  There will probably
be one more release in roughly two weeks, assuming we don't encounter
any high profile CVE issues in the interim.

There are just over 80 commits here, based on commits chosen from what
was used in existing 4.14.x stable releases.

I've put this 4.12.x queue through the usual testing that I figured made
sense, which is in line with that listed explicitly in previous release
announcements.

I did the signed tag just as per the previously released 4.12.x versions.

Please find a signed v4.12.28 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.12.x release.

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

[yocto] [layerindex-web][PATCH v2 00/31] Distro comparisons (cover letter only)

[Paul Eggleton]

After running some more tests with Fedora metadata I've made the
following fixes:

- Turns out fedora golang rpms already have the processed name so we don't
  need the stuff in rpmmacros.py, so drop that
- Add missing __grep definition
- Handle unbracketed expressions e.g. %name instead of %{name}
- Handle parentheses around conditional values as some spec files use
  these
- Support %undefine
- Fix logic for marking recipes as deleted, since pn might be different
  than the name we got from the spec file name
- Drop unused excludevalues parameter to expand() inner function


The following changes since commit fca74f3ac3c6536c50cb0a518fe78447a284dc55:

  Update TODO list (2018-08-06 12:36:31 +0200)

are available in the Git repository at:

  git://git.yoctoproject.org/layerindex-web paule/otherdistro
  http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/otherdistro

Paul Eggleton (31):
  forms: clear out comparison recipe/layerbranch if status doesn't
accept them
  Add a script to import layers from an existing layer index
  update_classic_status: fix matching on wrong layer
  Add partial path macro for vcs URL fields
  Add support for other distro comparisons
  Add script to import from other distros
  update_classic_status: update for other distro comparisons
  update_classic_status: set cover_pn from pn for direct match
  update_classic_status: use source URLs to match python/perl recipes
  update_classic_status: look for certain prefixes in order to match
  update_classic_status: add skip option
  Allow searching for uncategorised recipes in the comparison search
  Enhance filtering comparisons
  views: fix unknown categories comparison stats graph to include "Not
available"
  Add "needs attention" flag for comparison recipes
  Add support for importing Debian package info
  Support reversed other distro recipe list / filtering
  Support selecting more than one layer in other distro comparison
search form
  Support excluding inherited classes from other distro comparison
reversed query
  Add basic CSV export for other distro comparisons
  Add ability to store extra URLs to be displayed for comparison recipes
  rrs: show link to other distro comparison pages
  Rename LayerItem classic field to comparison
  Fix comparison layers showing up in dependencies list in edit layer
page
  Add ability to trigger comparison updates manually from UI
  Add script to fetch all repos under a github organisation
  Add script to fetch Fedora package sources
  Show source URLs on recipe detail page
  README: add setup info for other distro comparisons
  Add side-by-side comparison detail and enhanced selection
  Show links to include files on recipe detail

 README|  82 ++-
 TODO  |   2 -
 layerindex/admin.py   |   6 +
 layerindex/context_processors.py  |   4 +-
 layerindex/forms.py   |  37 +-
 layerindex/migrations/0015_comparison.py  |  24 +
 .../migrations/0016_classicrecipe_delete.py   |  19 +
 .../0017_classicrecipe_needs_attention.py |  19 +
 .../migrations/0018_layerrecipeextraurl.py|  26 +
 .../0019_layeritem_classic_comparison.py  |  25 +
 layerindex/migrations/0020_update_manual.py   |  50 ++
 layerindex/models.py  | 113 +++-
 layerindex/static/css/additional.css  |  20 +
 layerindex/tasks.py   |  23 +
 layerindex/templatetags/extrafilters.py   |  35 +
 layerindex/tools/fedora-fetch.py  | 170 +
 layerindex/tools/github-fetch.py  | 135 
 layerindex/tools/import_classic.py|   2 +-
 layerindex/tools/import_classic_wiki.py   |   2 +-
 layerindex/tools/import_layers.py | 251 
 layerindex/tools/import_otherdistro.py| 605 ++
 layerindex/tools/update_classic_status.py | 187 +-
 layerindex/update.py  |   8 +-
 layerindex/urls.py|  48 +-
 layerindex/urls_branch.py |   5 +-
 layerindex/utils.py   |   3 +
 layerindex/views.py   | 502 ++-
 templates/base.html   |   2 +
 templates/base_toplevel.html  |  16 +-
 templates/layerindex/classchecklist.html  |  21 +
 templates/layerindex/classic_base.html|  33 +-
 templates/layerindex/classicrecipedetail.html | 184 ++
 templates/layerindex/classicrecipes.html  | 324 +-
 templates/layerindex/classicrecipes_csv.txt   |   2 +
 templates/layerindex/classicstats.html|  16 +-
 .../layerindex/comparisonrecipebase.html  | 229 +++
 .../layerindex/comparisonrecipeselect.html| 119 
 .../comparisonrecipeselectdetail.html |  98 +++
 templates/layerindex/layerchecklist.html  |  21 +
 

Re: [yocto] custom splash screen using psplash

[Ricardo Ribalda Delgado]

And also note that if in the future you decide to use systemd, AFAIK
there is no progress bar there.
On Sun, Aug 12, 2018 at 8:32 PM Burton, Ross  wrote:
>
> The easy solution would be to not use meta-poky at all, but if you
> insist then you'll have to set the layer priority so bitbake uses your
> layer instead of meta-poky
>
> Ross
>
> On 9 August 2018 at 15:43, Yuvarajesh Valleru  wrote:
> > Hallo,
> >
> > I would like to overwrite the poky psplash splash screen [1] with my custom
> > splash screen.
> >
> > I copied the psplash_git.bb recipe from
> > openembedded-core/meta/recipes-core/psplash/ to my custom layer and changed
> > psplash_poky_img.h to mycustom_image_img.h in mycustom_recipe/files/
> >
> > But during the boot the Custom splash screen displays along with a progress
> > bar from poky splash screen. (I noticed that the psplash.c source file also
> > contains progress-bar.h file included)
> >
> > Is it possible to remove or overwrite the complete poky splash screen files
> > with mycustom_splashscreen?
> >
> > Thank you,
> >
> > Best Regards;
> > Rajesh
> >
> > [1]
> > https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-core/psplash/psplash_git.bb
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



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

Re: [yocto] [oe] [meta-openembedded] Original ltrace_git.bb SRCREV commit used is now unavailable in git tarball from ltrace.org

[Aditya Tayade]

Hi Randy,


Sent patch for this with below subject line:

[meta-oe][PATCH] ltrace: added alternate source


Thanks & Regards,

Aditya Tayade



From: Randy MacLeod 
Sent: Saturday, July 28, 2018 1:27 AM
To: Aditya Tayade; openembedded-iss...@lists.openembedded.org; 
openembedded-de...@lists.openembedded.org
Cc: yocto@yoctoproject.org; Nisha Parrakat
Subject: Re: [oe] [meta-openembedded] Original ltrace_git.bb SRCREV commit used 
is now unavailable in git tarball from ltrace.org

On 07/27/2018 06:34 AM, Aditya Tayade wrote:
> Hi,
>
>
> Me too facing same issue. Any advice on this.

Archived versions to fix previous releases may be here:

https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Falioth-archive.debian.org%2Fgit%2Fcollab-maint%2Fdata=02%7C01%7CAditya.Tayade%40kpit.com%7Ce77886ee683842dd047d08d5f3fb451f%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C636683182900149535sdata=UB%2F4VAlY8JydqNvYwsy4%2BDQd5Yfbz%2FPnMmzL9xp8GrY%3Dreserved=0

for master, a commit to pull from ltrace.org makes sense
to me but someone who follows debian development might
be able to help locate the git repo. All I found was:

https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Falioth-archive.debian.org%2Fgit%2Fcollab-maint%2Fdata=02%7C01%7CAditya.Tayade%40kpit.com%7Ce77886ee683842dd047d08d5f3fb451f%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C636683182900149535sdata=UB%2F4VAlY8JydqNvYwsy4%2BDQd5Yfbz%2FPnMmzL9xp8GrY%3Dreserved=0
and a maze of twisty little hyperlinks.

Aditya, Nisha,

Will you send a patch? See:

https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openembedded.org%2Fwiki%2FHow_to_submit_a_patch_to_OpenEmbeddeddata=02%7C01%7CAditya.Tayade%40kpit.com%7Ce77886ee683842dd047d08d5f3fb451f%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C636683182900149535sdata=gsSW5cWRMpdL%2F7TLEVcj5K1kYfDbWZstw22RiSSGA%2BY%3Dreserved=0

../Randy


>
>
>
> Regards,
>
> Aditya Tayade
>
> 
> From: Nisha Parrakat
> Sent: Tuesday, July 24, 2018 4:08:12 PM
> To: openembedded-iss...@lists.openembedded.org; 
> openembedded-de...@lists.openembedded.org
> Cc: yocto@yoctoproject.org
> Subject: [meta-openembedded] Original ltrace_git.bb SRCREV commit used is now 
> unavailable in git tarball from ltrace.org
>
>
> Hi all,
>
>
> ltrace recipe is pointing to a fetch url 
> (git://anonscm.debian.org/collab-maint/ltrace.git;branch=master) that is 
> discontinued now.
>
> No ltrace found in alternate salsa.debian.org.
>
> Tarball for ltrace is present in ltrace.org but the SRCREV in the mentioned 
> in the original recipe is not found any more but we do see the same commit 
> with another sha but a different git history.
>
>
> Please advice if we should modify the SRCREV to reflect the new git source 
> from ltrace.org?
>
>
> original SRCREV in recipe c22d3594...
>
> corresponding SRCREV coming from the git tarball is ea8928da...
>
>
> Please advice .
>
>
>
>
> Regards,
> Ms Nisha Parrakat
> KPIT Technologies Ltd, Pune, INDIA
>
>
> This message contains information that may be privileged or confidential and 
> is the property of the KPIT Technologies Ltd. It is intended only for the 
> person to whom it is addressed. If you are not the intended recipient, you 
> are not authorized to read, print, retain copy, disseminate, distribute, or 
> use this message or any part thereof. If you receive this message in error, 
> please notify the sender immediately and delete all copies of this message. 
> KPIT Technologies Ltd. does not accept any liability for virus infected mails.
>


--
# Randy MacLeod
# Wind River Linux
This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH 1/1] cfg: add fragment for kernel-selftest

[Hongzhi.Song]

When you want to run cases under tool/testing/selftest of
kernel-source, these fragments are required.

Signed-off-by: Hongzhi.Song 
---
 cfg/debug-kselftest.cfg | 70 +
 cfg/debug-kselftest.scc |  4 +++
 2 files changed, 74 insertions(+)
 create mode 100644 cfg/debug-kselftest.cfg
 create mode 100644 cfg/debug-kselftest.scc

diff --git a/cfg/debug-kselftest.cfg b/cfg/debug-kselftest.cfg
new file mode 100644
index ..e33c8fa8
--- /dev/null
+++ b/cfg/debug-kselftest.cfg
@@ -0,0 +1,70 @@
+# bpf
+CONFIG_BPF=y
+CONFIG_BPF_SYSCALL=y
+CONFIG_NET_CLS_BPF=m
+CONFIG_BPF_EVENTS=y
+CONFIG_TEST_BPF=m
+# cpu-hotplug
+CONFIG_NOTIFIER_ERROR_INJECTION=y
+# cpu freq
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
+CONFIG_DEBUG_RT_MUTEXES=y
+CONFIG_DEBUG_PI_LIST=y
+CONFIG_DEBUG_SPINLOCK=y
+CONFIG_DEBUG_MUTEXES=y
+CONFIG_DEBUG_LOCK_ALLOC=y
+CONFIG_PROVE_LOCKING=y
+CONFIG_LOCKDEP=y
+CONFIG_DEBUG_ATOMIC_SLEEP=y
+# firmware
+CONFIG_TEST_FIRMWARE=y
+CONFIG_KPROBES=y
+# ftrace
+CONFIG_FTRACE=y
+# ipc
+CONFIG_EXPERT=y
+CONFIG_CHECKPOINT_RESTORE=y
+CONFIG_TEST_KMOD=m
+CONFIG_TEST_LKM=m
+CONFIG_XFS_FS=m
+
+# For the module parameter force_init_test is used
+# kmod
+CONFIG_TUN=m
+CONFIG_BTRFS_FS=m
+# net
+CONFIG_USER_NS=y
+CONFIG_BPF_SYSCALL=y
+CONFIG_TEST_BPF=m
+# netfs
+CONFIG_USER_NS=y
+CONFIG_UTS_NS=y
+CONFIG_PID_NS=y
+# pstore
+CONFIG_MISC_FILESYSTEMS=y
+CONFIG_PSTORE=y
+CONFIG_PSTORE_PMSG=y
+CONFIG_PSTORE_CONSOLE=y
+# seccomp
+CONFIG_SECCOMP=y
+CONFIG_SECCOMP_FILTER=y
+# static_keys
+CONFIG_TEST_STATIC_KEYS=m
+# sysctl
+CONFIG_TEST_SYSCTL=y
+# user
+CONFIG_TEST_USER_COPY=m
+# vm
+CONFIG_SYSVIPC=y
+CONFIG_USERFAULTFD=y
+CONFIG_HUGETLB_PAGE=y
+CONFIG_HUGETLBFS=y
+# zram
+CONFIG_ZSMALLOC=y
+CONFIG_ZRAM=m
diff --git a/cfg/debug-kselftest.scc b/cfg/debug-kselftest.scc
new file mode 100644
index ..bf138ed8
--- /dev/null
+++ b/cfg/debug-kselftest.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "When you want to run cases under \
+tool/testing/selftest of kernel-source, these fragments are required."
+
+kconf non-hardware debug-kselftest.cfg
-- 
2.11.0

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

[linux-yocto] [PATCH 0/1] add a feature for kernel selftest

[Hongzhi.Song]

Please merge this to 4.15 and master 

Hongzhi.Song (1):
  cfg: add fragment for kernel-selftest

 cfg/debug-kselftest.cfg | 70 +
 cfg/debug-kselftest.scc |  4 +++
 2 files changed, 74 insertions(+)
 create mode 100644 cfg/debug-kselftest.cfg
 create mode 100644 cfg/debug-kselftest.scc

-- 
2.11.0

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

Re: [yocto] [PATCH][meta-dpdk] dpdk-dev-libibverbs: fix do_fetch error

[Anuj Mittal]

On 08/13/2018 01:22 PM, changqing...@windriver.com wrote:
> From: Changqing Li 
> 
> original URI have been deleted(don't know why). I noticed there is
> an official libibverbs(https://git.kernel.org/pub/scm/libs/infiniband
> /libibverbs.git), 

The deprecation notice seems to imply that rdma-core on github should be
used instead and that's what debian does too. Perhaps that should be
used instead?

https://tracker.debian.org/pkg/rdma-core

> but there are big differences with original one.
> I don't have condition to test this now, I can only go as far as builds
> OK. so I select use tar.gz on yocto to make sure fetch can success and
> original function not be affected.
> 
> I also noticed a project seems like Mellanox libibverbs,
> https://github.com/gpudirect/libibverbs, but it don't have any
> official release now.
> 
> Hope in the future, we can switch to the offcial libibverbs, or
> the new Mellanox libibverbs. but now, we use this yocto tar.gz
> as a workaround to make it at least work now.

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