Re: [yocto] [meta-selinux][PATCH] refpolicy: Update to 20180114 release

[Yi Zhao]

Ping


//Yi


在 2018年04月27日 17:30, wenzong@windriver.com 写道:

From: Wenzong Fan 

Remove patches that included by upstream:
- poky-fc-nscd.patch
- poky-fc-ftpwho-dir.patch
- refpolicy-update-for_systemd.patch
- 0005-refpolicy-minimum-init-fix-reboot-with-systemd-as-in.patch

Rebase patches:
- poky-fc-clock.patch
- poky-fc-dmesg.patch
- poky-fc-fix-real-path_login.patch
- poky-fc-fix-real-path_shadow.patch
- poky-fc-fix-real-path_su.patch
- poky-fc-fstools.patch
- poky-fc-netutils.patch
- poky-fc-ssh.patch
- poky-fc-sysnetwork.patch
- poky-fc-udevd.patch
- poky-fc-update-alternatives_bash.patch
- poky-fc-update-alternatives_hostname.patch
- poky-fc-update-alternatives_sysklogd.patch
- poky-fc-update-alternatives_sysvinit.patch
- poky-policy-add-rules-for-syslogd_t-symlink.patch
- poky-policy-add-rules-for-var-log-symlink-apache.patch
- poky-policy-add-rules-for-var-log-symlink.patch
- poky-policy-allow-nfsd-to-exec-shell-commands.patch
- poky-policy-allow-setfiles_t-to-read-symlinks.patch
- poky-policy-fix-dmesg-to-use-dev-kmsg.patch
- poky-policy-fix-setfiles-statvfs-get-file-count.patch
- 0001-refpolicy-minimum-systemd-unconfined-lib-add-systemd.patch
- 0007-refpolicy-minimum-systemd-fix-for-login-journal-serv.patch
- 0008-refpolicy-minimum-systemd-fix-for-systemd-tmp-files-.patch

Add a new patch for minimum:
- 0010-refpolicy-minimum-systemd-make-fstools_write_log-opt.patch

Signed-off-by: Wenzong Fan 
---
  .../refpolicy-2.20170204/poky-fc-ftpwho-dir.patch  |  27 -
  .../refpolicy-2.20170204/poky-fc-nscd.patch|  25 -
  .../refpolicy-update-for_systemd.patch |  27 -
  .../ftp-add-ftpd_t-to-mlsfilewrite.patch   |   0
  .../poky-fc-clock.patch|  20 ++--
  .../poky-fc-corecommands.patch |   0
  .../poky-fc-dmesg.patch|  13 ++-
  .../poky-fc-fix-bind.patch |   0
  .../poky-fc-fix-real-path_login.patch  |  47 
  .../poky-fc-fix-real-path_resolv.conf.patch|   0
  .../poky-fc-fix-real-path_shadow.patch |  36 --
  .../poky-fc-fix-real-path_su.patch |  15 ++-
  .../poky-fc-fstools.patch  |  79 -
  .../poky-fc-iptables.patch |   0
  .../poky-fc-mta.patch  |   0
  .../poky-fc-netutils.patch |  28 ++---
  .../poky-fc-rpm.patch  |   0
  .../poky-fc-screen.patch   |   0
  .../poky-fc-ssh.patch  |  16 +--
  .../poky-fc-su.patch   |   0
  .../poky-fc-subs_dist.patch|   0
  .../poky-fc-sysnetwork.patch   |  43 +++-
  .../poky-fc-udevd.patch|  35 ++
  .../poky-fc-update-alternatives_bash.patch |  30 ++---
  .../poky-fc-update-alternatives_hostname.patch |  15 ++-
  .../poky-fc-update-alternatives_sysklogd.patch |  51 +
  .../poky-fc-update-alternatives_sysvinit.patch |  68 ++--
  ...poky-policy-add-rules-for-bsdpty_device_t.patch |   0
  ...ky-policy-add-rules-for-syslogd_t-symlink.patch |  16 +--
  .../poky-policy-add-rules-for-tmp-symlink.patch|   0
  ...ky-policy-add-rules-for-var-cache-symlink.patch |   0
  ...licy-add-rules-for-var-log-symlink-apache.patch |  16 +--
  ...rules-for-var-log-symlink-audisp_remote_t.patch |   0
  ...poky-policy-add-rules-for-var-log-symlink.patch | 122 -
  ...ky-policy-add-syslogd_t-to-trusted-object.patch |   0
  ...-policy-allow-nfsd-to-exec-shell-commands.patch |  35 +-
  ...-policy-allow-setfiles_t-to-read-symlinks.patch |  18 +--
  .../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|  30 ++---
  .../poky-policy-fix-new-SELINUXMNT-in-sys.patch|   0
  ...poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch |   0
  ...olicy-fix-setfiles-statvfs-get-file-count.patch |  20 ++--
  ...ky-policy-fix-seutils-manage-config-files.patch |   0
  ...s_2.20170204.bb => refpolicy-mcs_2.20180114.bb} |   0
  ...inimum-systemd-unconfined-lib-add-systemd.patch |  35 ++
  ...inimum-init-fix-reboot-with-systemd-as-in.patch |  36 --
  ...inimum-systemd-fix-for-login-journal-serv.patch |  47 +---
  ...inimum-systemd-fix-for-systemd-tmp-files-.patch |  56 +-
  ...inimum-systemd-make-fstools_write_log-opt.patch |  36 ++
  ...20170204.bb => refpolicy-minimum_2.20180114.bb} |   2 +-
  ...s_2.20170204.bb => refpolicy-mls_2.20180114.bb} |   0
  ...0170204.bb => refpolicy-standard_2.20180114.bb} |   0
  ...0170204.bb => refpolicy-targeted_2.20180114.bb} |   0
  ...icy_2.20170204.inc => refpolicy_2.20180114.inc} |   9 +-
  55 files changed, 413 insertions(+), 640 deletions(-)
  delete mode 100644 

Re: [yocto] [PATCH] [yocto-autobuilder] init: Fix the import module yoctoabb & yocto_console_view

[Chan, Aaron Chun Yew]

Hi Richard,

It appears that your using virtualenv (switch to python3) to startup your 
buildbot processes and not using the default python from host distribution.
I am aware that you can switch interpreter to python2/3 in virtualenv. 
Shouldn’t we handle these for both in events users uses
the default host distribution as default python2 and still make it worked? What 
is the best practices here and should all the buildbot-workers start in
virtualenv defaults to python3 as well ? I am little lost right here, please 
advise.

Cheers,
Aaron

Try using virtualenv:

$ python --version
Python 2.7.15rc1

$ virtualenv -p python3 test
Already using interpreter /usr/bin/python3 Using base prefix '/usr'
New python executable in /media/build1/test/bin/python3 Also creating 
executable in /media/build1/test/bin/python Installing setuptools, 
pkg_resources, pip, wheel...done.

$ . ./test/bin/activate

(test) richard@dax:/media/build1/$ python --version Python 3.6.5


If you start buildbot within the virtualenv, you should see it using python3.

Cheers,

Richard

-Original Message-
From: richard.pur...@linuxfoundation.org 
[mailto:richard.pur...@linuxfoundation.org] 
Sent: Wednesday, July 11, 2018 6:17 AM
To: Chan, Aaron Chun Yew ; 
yocto@yoctoproject.org; Burton, Ross ; Eggleton, Paul 

Subject: Re: [PATCH] [yocto-autobuilder] init: Fix the import module yoctoabb & 
yocto_console_view

On Tue, 2018-07-10 at 10:47 +, Chan, Aaron Chun Yew wrote:
> [Richard] I think this means you're using python2 and we really should
> be using
> python3 as I don't want to support both...
> 
> [Reply] This error/bug was found during buildbot startup meaning this 
> is out of my control.

No, it is not out of your control.

> Maybe you have a fix for this, otherwise I do suggest to 
> add in __init__.py in places where we need to source custom modules.
> 
> $ buildbot start ~/yocto-controller
> $ cat -n 100 ~/yocto-controller/twistd.log

Try using virtualenv:

$ python --version
Python 2.7.15rc1

$ virtualenv -p python3 test
Already using interpreter /usr/bin/python3 Using base prefix '/usr'
New python executable in /media/build1/test/bin/python3 Also creating 
executable in /media/build1/test/bin/python Installing setuptools, 
pkg_resources, pip, wheel...done.

$ . ./test/bin/activate

(test) richard@dax:/media/build1/$ python --version Python 3.6.5


If you start buildbot within the virtualenv, you should see it using python3.

Cheers,

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

Re: [yocto] [PATCH] [yocto-autobuilder] init: Fix the import module yoctoabb & yocto_console_view

[Richard Purdie]

On Tue, 2018-07-10 at 10:47 +, Chan, Aaron Chun Yew wrote:
> [Richard] I think this means you're using python2 and we really
> should be using
> python3 as I don't want to support both...
> 
> [Reply] This error/bug was found during buildbot startup meaning this
> is out of my control.

No, it is not out of your control.

> Maybe you have a fix for this, otherwise I do suggest to
> add in __init__.py in places where we need to source custom modules.
> 
> $ buildbot start ~/yocto-controller
> $ cat -n 100 ~/yocto-controller/twistd.log

Try using virtualenv:

$ python --version
Python 2.7.15rc1

$ virtualenv -p python3 test
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /media/build1/test/bin/python3
Also creating executable in /media/build1/test/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.

$ . ./test/bin/activate

(test) richard@dax:/media/build1/$ python --version
Python 3.6.5


If you start buildbot within the virtualenv, you should see it using
python3.

Cheers,

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

Re: [yocto] Hook for layer-only actions?

[Jeremy Puhlman]

On 7/10/2018 1:04 PM, Michael Habibi wrote:
Well I should have just used what I want to actually do as the 
example, and not a QA action.


I want to create a new type of manifest that is only my layer, that 
will include line items that basically has like: package name, 
version, download URL, checksum, license.


I have no idea yet how to implement it, but wanted to make sure it was 
feasible.


It is.

You more or less just need to figure out which layer the recipe comes 
from. Then you can build functions on top of that.


https://github.com/MontaVista-OpenSourceTechnology/meta-montavista-cgx/blob/master/conf/layerinfo.inc

We modify the mirror we point to based on what layer the recipe resides 
in...The specific function that would interest you is

get_layername

Which we set LAYER_NAME to, then we use functions to do things with 
LAYER_NAME.




On Tue, Jul 10, 2018 at 2:27 PM Burton, Ross > wrote:


Hypothetically a new QA action should be added at the distro level, by
writing a class and adding it to INHERIT.

(I've several new QA tests added in this way)

Ross

On 10 July 2018 at 19:53, Alexander Kanavin
mailto:alex.kana...@gmail.com>> wrote:
> Yes. Implement a class and inherit it from the recipes.
>
> Alex
>
> 2018-07-10 20:50 GMT+02:00 Michael Habibi mailto:mikehab...@gmail.com>>:
>> I was wondering if there is a way I can apply a global
modification to all
>> recipes in a layer? For instance, we have our own layer for our
changes that
>> sit on top of the base Yocto/OE layers.
>>
>> What if, hypothetically, I wanted to insert a do_package_qa
action globally,
>> for everything in our layer. Is there a way to codify that,
beyond actually
>> adding this to every recipe in our layer?
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org 
>> https://lists.yoctoproject.org/listinfo/yocto
>>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto





--
Jeremy A. Puhlman
jpuhl...@mvista.com

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

Re: [yocto] Hook for layer-only actions?

[Michael Habibi]

Well I should have just used what I want to actually do as the example, and
not a QA action.

I want to create a new type of manifest that is only my layer, that will
include line items that basically has like: package name, version, download
URL, checksum, license.

I have no idea yet how to implement it, but wanted to make sure it was
feasible.

On Tue, Jul 10, 2018 at 2:27 PM Burton, Ross  wrote:

> Hypothetically a new QA action should be added at the distro level, by
> writing a class and adding it to INHERIT.
>
> (I've several new QA tests added in this way)
>
> Ross
>
> On 10 July 2018 at 19:53, Alexander Kanavin 
> wrote:
> > Yes. Implement a class and inherit it from the recipes.
> >
> > Alex
> >
> > 2018-07-10 20:50 GMT+02:00 Michael Habibi :
> >> I was wondering if there is a way I can apply a global modification to
> all
> >> recipes in a layer? For instance, we have our own layer for our changes
> that
> >> sit on top of the base Yocto/OE layers.
> >>
> >> What if, hypothetically, I wanted to insert a do_package_qa action
> globally,
> >> for everything in our layer. Is there a way to codify that, beyond
> actually
> >> adding this to every recipe in our layer?
> >>
> >> --
> >> ___
> >> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Including a header from an external kernel module

[Andre McCurdy]

On Tue, Jul 10, 2018 at 12:11 AM, Michael Allwright
 wrote:
> Am I correct in expecting that, if I do everything correctly, my header file
> from module-a should end up in
> ~/poky/build/tmp/work-shared/machine/kernel-source/include/linux/mfd

No, the kernel-source directory is for the kernel recipe and other
recipes can't generally add anything too it (if you want a header to
show up in the kernel source directory then you could patch the kernel
sources though).

Other (ie non-kernel) recipes share headers etc via sysroot, which
with OE 2.3 and above is created for each recipe in the
"recipe-sysroot" subdirectory in the recipe's WORKDIR.

>From what you've said so far, I guess module-a's header file is in
module-b's sysroot directory under /usr/include, but when module-b is
compiled the include path isn't setup to find it.

Since /usr/include in sysroot contains headers for user space it's
quite correct that it shouldn't be in the include path when building a
kernel module (e.g. to prevent accidentally including user space
string.h instead of the kernel version, etc, etc). When the kbuild
Makefiles call the compiler they will not pass a --sysroot option etc.

If module-a is sharing a header in a subdirectory of sysroot, you will
need to somehow manually add that directory as an extra include path
when module-b is compiled (don't try to add the whole of sysroot
/usr/include - just the specific subdirectory you need).

A possible alternative approach might be to create one recipe which
builds all your kernel modules. That would make the build self more
contained as each module can find headers from other modules somewhere
in ${S}.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Hook for layer-only actions?

[Burton, Ross]

Hypothetically a new QA action should be added at the distro level, by
writing a class and adding it to INHERIT.

(I've several new QA tests added in this way)

Ross

On 10 July 2018 at 19:53, Alexander Kanavin  wrote:
> Yes. Implement a class and inherit it from the recipes.
>
> Alex
>
> 2018-07-10 20:50 GMT+02:00 Michael Habibi :
>> I was wondering if there is a way I can apply a global modification to all
>> recipes in a layer? For instance, we have our own layer for our changes that
>> sit on top of the base Yocto/OE layers.
>>
>> What if, hypothetically, I wanted to insert a do_package_qa action globally,
>> for everything in our layer. Is there a way to codify that, beyond actually
>> adding this to every recipe in our layer?
>>
>> --
>> ___
>> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Hook for layer-only actions?

[Alexander Kanavin]

Yes. Implement a class and inherit it from the recipes.

Alex

2018-07-10 20:50 GMT+02:00 Michael Habibi :
> I was wondering if there is a way I can apply a global modification to all
> recipes in a layer? For instance, we have our own layer for our changes that
> sit on top of the base Yocto/OE layers.
>
> What if, hypothetically, I wanted to insert a do_package_qa action globally,
> for everything in our layer. Is there a way to codify that, beyond actually
> adding this to every recipe in our layer?
>
> --
> ___
> 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] Hook for layer-only actions?

[Michael Habibi]

I was wondering if there is a way I can apply a global modification to all
recipes in a layer? For instance, we have our own layer for our changes
that sit on top of the base Yocto/OE layers.

What if, hypothetically, I wanted to insert a do_package_qa action
globally, for everything in our layer. Is there a way to codify that,
beyond actually adding this to every recipe in our layer?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] dtb mising from raspberrypi3-64.conf

[Steve Pavao]

Would you please add the bcm2710-rpi-cm3.dtb to the KERNEL_DEVICETREE listing 
in raspberrypi3-64.conf in sumo branch?  It’s missing.

- Steve Pavao
Korg R

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

[yocto] [ANNOUNCEMENT] Milestone 1 for Yocto Project 2.6 (yocto-2.6_M1) now available

[Tracy Graydon]

We are pleased to announce the first milestone release for Yocto Project 2.6 
(yocto-2.6_M1) is available for download now.

Download:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.6_M1/

poky ddbd7b0cd6580ee26e11aa87e426fb294b372d64
eclipse-poky-neon a5dbc01b96be55c4ec2f774af9996a8086e402ab
eclipse-poky-oxygen fbb91e5c5ad06470cd50ce1daa407a5f7d13c6ca  
meta-qt3 02f273cba6c25f5cf20cb66d8a417a83772c3179
meta-qt4 8e791c40140460825956430ba86b6266fdec0a93


Test report:

https://wiki.yoctoproject.org/wiki/WW27_-_2018-07-02_-_Full_Test_Cycle_2.6_M1_rc1

Thank you.

Tracy Graydon
Yocto Project Build and Release
tracy.gray...@intel.com




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

[yocto-announce] [ANNOUNCEMENT] Milestone 1 for Yocto Project 2.6 (yocto-2.6_M1) now available

[Tracy Graydon]

We are pleased to announce the first milestone release for Yocto Project 2.6 
(yocto-2.6_M1) is available for download now.

Download:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.6_M1/

poky ddbd7b0cd6580ee26e11aa87e426fb294b372d64
eclipse-poky-neon a5dbc01b96be55c4ec2f774af9996a8086e402ab
eclipse-poky-oxygen fbb91e5c5ad06470cd50ce1daa407a5f7d13c6ca  
meta-qt3 02f273cba6c25f5cf20cb66d8a417a83772c3179
meta-qt4 8e791c40140460825956430ba86b6266fdec0a93


Test report:

https://wiki.yoctoproject.org/wiki/WW27_-_2018-07-02_-_Full_Test_Cycle_2.6_M1_rc1

Thank you.

Tracy Graydon
Yocto Project Build and Release
tracy.gray...@intel.com




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

[yocto] LLVM: error adding symbols: File in wrong format

[Giordon Stark]

Hi all,

|
/local/d4/gstark/poky/build/tmp/work/aarch64-poky-linux/root/6.14.00-r0/recipe-sysroot-native/usr/lib/libLLVMSupport.a:
error adding symbols: File in wrong format
| clang-5.0: error: linker command failed with exit code 1 (use -v to see
invocation)
|
interpreter/llvm/src/tools/clang/utils/TableGen/CMakeFiles/clang-tblgen.dir/build.make:95:
recipe for target 'interpreter/llvm/src/bin/clang-tblgen' failed
| make[2]: *** [interpreter/llvm/src/bin/clang-tblgen] Error 1
| make[2]: Leaving directory
'/local/d4/gstark/poky/build/tmp/work/aarch64-poky-linux/root/6.14.00-r0/build'
| CMakeFiles/Makefile2:791: recipe for target
'interpreter/llvm/src/tools/clang/utils/TableGen/CMakeFiles/clang-tblgen.dir/all'
failed
| make[1]: ***
[interpreter/llvm/src/tools/clang/utils/TableGen/CMakeFiles/clang-tblgen.dir/all]
Error 2
| make[1]: *** Waiting for unfinished jobs

Here's the full log:
https://gist.github.com/3403addf74b5e902adec93b75fb0e138

Any ideas how to get a more verbose invocation if needed? I suspect the
error is due to some pre-built libraries being shipped in this recipe, but
I'm not sure what's causing the error in the first place.

Note: I am using meta-clang. The recipe I'm using looks like:

SUMMARY = "Numerical data analysis framework (OO)"
DESCRIPTION = "Object oriented framework for large scale data analysis"
HOMEPAGE = "http://root.cern.ch;
LICENSE = "LGPLv2.1"
LIC_FILES_CHKSUM = "file://LICENSE;md5=5ec773ab82cbea1f17ec5b98e8ce60cf"
SRC_URI = "https://root.cern.ch/download/root_v${PV}.source.tar.gz;

S = "${WORKDIR}/${BPN}-${PV}"

TOOLCHAIN = "clang"
#TARGET_CXXFLAGS_append_toolchain-clang = " -stdlib=libc++ "

DEPENDS += "llvm-native libpcre lz4 libx11 libxpm libxft gsl fftw
libatomic-ops freetype glew xrootd"

inherit cmake pkgconfig pythonnative


do_configure_prepend(){
export FC=${GFORTRAN}
}

EXTRA_OECMAKE = "\
-Drootfit=ON \
-Dminuit2=ON \
-Dpython=ON \
-Dssl=ON \
-Dxrootd=ON \
-Dbuiltin_freetype=OFF \
-Dbuiltin_llvm=OFF \
-Dbuiltin_glew=OFF \
-Dastiff=OFF \
-Dasimage=OFF \
-Dbuiltin_afterimage=OFF \
-Dalien=OFF \
-Dvdt=OFF \
"

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

Re: [linux-yocto] [yocto-4.14][PATCH] cfg: add fragment on kernel selftest

[Bruce Ashfield]

On 07/08/2018 11:39 PM, Hongzhi.Song wrote:

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


merged to 4.14

Bruce



Signed-off-by: Hongzhi.Song 
---
  cfg/debug-kselftest.cfg | 68 +
  cfg/debug-kselftest.scc |  4 +++
  2 files changed, 72 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 000..7b22d1b
--- /dev/null
+++ b/cfg/debug-kselftest.cfg
@@ -0,0 +1,68 @@
+# 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
+# zram
+CONFIG_ZSMALLOC=y
+CONFIG_ZRAM=m
diff --git a/cfg/debug-kselftest.scc b/cfg/debug-kselftest.scc
new file mode 100644
index 000..bf138ed
--- /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



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

[yocto] [layerindex-web] RFC: layer index docker fixes

[Paul Eggleton]

Hi folks

I've been trying to get the OE layer index example docker setup in shape,
based upon improvements from myself, Michael and Konrad. For the moment I've
taken most of what Michael and I did (with some fixes and tweaks, and broken up
into smaller patches) and a few pieces of the Dockerfile from Konrad's recent
patch and put it here:

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

Konrad, I know you were a little bit more ambitious with your changes but I 
wanted to get something closer to what Michael is using and then we can build 
upon it. In particular I haven't yet explored docker-compose as you have,
although it looks like it would make deploying all of this a bit easier. 

Let me know what you think.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] [layerindex-web][PATCH 1/6] Add docker-compose file to create full layerindex stack of MariaDB, RabbitMQ and Nginx

[Paul Eggleton]

Hi Konrad

On Tuesday, 26 June 2018 7:41:30 PM CEST Konrad Scherer wrote:
> Lots of new features added:
> 
> - Layerindex runs as unprivileged user inside container
> 
> - Celery worker is started before gunicorn
> 
> - Entrypoint script supports changing RabbitMQ location
> 
> - Entrypoint script support initialization of database and superuser
> 
> - Reverse Proxy uses https with self signed certs by default and
>   supports Let's Encrypt certs (not enabled by default)
> 
> - Move docker image to debian stretch and python3
> 
> - Remove build tools after installation to reduce the image
>   to under 500MB in size

This is quite nice, thanks!

Coincidentally, both myself and Michael Halstead have had a go at cleaning up
and improving the Docker setup, so I have to do a little reconciliation
between your and his changes - see here for his:

https://github.com/halstead/layerindex-web/commit/b9791710ff97550fa9110ab89a70c42b1fc86581

I think we probably want to break all of this down into a set of discrete 
commits rather than one big one, and then it'll be a bit clearer. I'll do a
first pass and come back to you both.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [linux-yocto] [PATCH] intel-x86: Add intel-x86 BSPs

[Bruce Ashfield]

On 07/10/2018 05:01 AM, Liu, Yongxin wrote:


This is mainly used for Wind River intel-x86 BSP.


Correct. And I had asked for this to be posted, so I could get
it into the kernel-cache, where we could look for common
configuration blocks, etc, and gradually move to less duplicated
elements.

For various reasons (linux-yocto version, conflicting / different
requirements, ...) the meta-intel or common-pc BSP weren't suitable
in the past. But by exposing this, we have a chance to see where
the delta now sits.

Cheers,

Bruce




Thanks,
Yongxin


-Original Message-
From: Anuj Mittal [mailto:anuj.mit...@intel.com]
Sent: Tuesday, July 10, 2018 16:53
To: Liu, Yongxin; linux-yocto@yoctoproject.org
Subject: Re: [linux-yocto] [PATCH] intel-x86: Add intel-x86 BSPs

On 07/10/2018 03:52 PM, Yongxin Liu wrote:

Create intel-x86-32/64 descriptions in yocto-kernel-cache.
These BSPs include all the core support for intel-x86 BSP.

This is an initial step to get the machines available and testing.

Signed-off-by: Yongxin Liu 
---
  bsp/intel-x86/cfs-bandwidth.cfg |   1 +
  bsp/intel-x86/intel-x86-32-standard.scc |  10 +
  bsp/intel-x86/intel-x86-32.cfg  |  23 ++
  bsp/intel-x86/intel-x86-32.scc  |   6 +
  bsp/intel-x86/intel-x86-64-standard.scc |   9 +
  bsp/intel-x86/intel-x86-64.cfg  |  51 
  bsp/intel-x86/intel-x86-64.scc  |   9 +
  bsp/intel-x86/intel-x86-acpi.cfg|  16 ++
  bsp/intel-x86/intel-x86-hugepage.cfg|   2 +
  bsp/intel-x86/intel-x86-igb-overrides.cfg   |   1 +
  bsp/intel-x86/intel-x86-ixgbe-overrides.cfg |   1 +
  bsp/intel-x86/intel-x86-mga.cfg |   3 +
  bsp/intel-x86/intel-x86.cfg | 370 
  bsp/intel-x86/intel-x86.scc |  46 
  14 files changed, 548 insertions(+)
  create mode 100644 bsp/intel-x86/cfs-bandwidth.cfg
  create mode 100644 bsp/intel-x86/intel-x86-32-standard.scc
  create mode 100644 bsp/intel-x86/intel-x86-32.cfg
  create mode 100644 bsp/intel-x86/intel-x86-32.scc
  create mode 100644 bsp/intel-x86/intel-x86-64-standard.scc
  create mode 100644 bsp/intel-x86/intel-x86-64.cfg
  create mode 100644 bsp/intel-x86/intel-x86-64.scc
  create mode 100644 bsp/intel-x86/intel-x86-acpi.cfg
  create mode 100644 bsp/intel-x86/intel-x86-hugepage.cfg
  create mode 100644 bsp/intel-x86/intel-x86-igb-overrides.cfg
  create mode 100644 bsp/intel-x86/intel-x86-ixgbe-overrides.cfg
  create mode 100644 bsp/intel-x86/intel-x86-mga.cfg
  create mode 100644 bsp/intel-x86/intel-x86.cfg
  create mode 100644 bsp/intel-x86/intel-x86.scc


I am just curious, how is this different from what is enabled via
intel-common or common-pc?

Thanks,

Anuj



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

Re: [yocto] SRC_URI git from ssh fails

[Mauro Ziliani]

Now it works.

But it was a problem of git repository.

I rebuild the SRCREC on the repository and now I acan fetch the source code.


I choose this recipe method.

PV="1.0"

SRCREV="refs/tags/${PV}"


SRC_URI = " \
    git://user@server/repos.git;protocol=ssh \
"

Thanks for the help

MZ

Il 10/07/2018 10:40, Martin Hundebøll ha scritto:

Hi again,

On 2018-07-10 10:37, Martin Hundebøll wrote:

Hi Mauro,

On 2018-07-10 10:31, Mauro Ziliani wrote:

Hi all

I'm working with Krogoth and imx6dlsabresd board.

I'm in trouble fetching source code from a git repository via ssh.

If I get manually the source codes with

git clone ssh://user@server/repos.git -b 0.4

it works


If I put it in myrecipe_git.bb with


SRC_URI = " \

    git://user@server/repos.git;protocol=ssh;tag=0.4 \

"


You might get lucky with a colon instead of the slash:

 git://user@server:repos.git;protocol=ssh;tag=0.4

But it is just a wild guess, and I didn't really test it :)

// Martin



S="${WORKDIR}/${PN}-${PV}"


the fecth task fails.


I try also SRCREV="0.4" outside SRC_URI and rev=0.4 in place of tag=0.4


Oh, don't base your checkouts on tags, as they can change without 
bitbake noticing.


Put a commit id in SRCREV instead and look into AUTOREV if you need to 
always build the latest and greatest.


// Martin



Where I mistake?


Thanks


MZ








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

Re: [yocto] [PATCH] [yocto-autobuilder] master.cfg: Defaults autobuilder URL based on FQDN

[Chan, Aaron Chun Yew]

Hi Richard,

[Richard] I appreciate what you're trying to do here and make this 
autoconfigure.
 Unfortunately the urls can't always be figured out this way, the above
for example drops the "/main/" part, without which the autobuilder
won't work. The server can be behind forwarding or proxies/firewalls
which also make this problematic.

I also agree with Martin that using os.path.join() in a url is
incorrect, its not meant for urls.

Most people setting up an autobuilder will need to have some
customisations on top of yocto-autobuilder2, I don't think its possible
to avoid that. I'd therefore perhaps try and concentrate on having key
modules like the lava integration available and accept there will
always be some local configuration the end user needs to make to things
like the URL details? Even the main autobuilder adds in passwords and
some other local config on top of the stardard repo...

[Reply] I do agree with you that some customization are required to be built on 
top of autobuilder.
However this patch is submitted because the URL link below is not 
working on my end and
only http://localhost:8010/ is working without the need to change 
the master.cfg
So therefore, due to several rounds of commission i decided to send 
a patch which defaults
URL following the FQDN sets on the host machines.

c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;

c['buildbotURL'] = "http://localhost:8010/'

The intention of this patch is to reduce the need for local configurations, yes 
I do agree that there will
be some level of customization needed on local setup. I'll leave it to you then 
to determine whats best.

Cheers,
Aaron


From: richard.pur...@linuxfoundation.org [richard.pur...@linuxfoundation.org]
Sent: Tuesday, July 10, 2018 4:55 PM
To: Chan, Aaron Chun Yew; yocto@yoctoproject.org; Burton, Ross; Eggleton, Paul
Subject: Re: [PATCH] [yocto-autobuilder] master.cfg: Defaults autobuilder URL 
based on FQDN

On Tue, 2018-07-10 at 11:18 +0800, Aaron Chan wrote:
> This patch is to enable auto-assignments buildbot URL based on Hosts FQDN.
> The socket module allows the retrieval on FQDN and constructs the entire
> URL by default, this default settings can be overwritten in c['buildbotURL']
> based on local administrator preferences.
>
> Signed-off-by: Aaron Chan 
> ---
>  master.cfg | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/master.cfg b/master.cfg
> index fca80d2..49ddeb4 100644
> --- a/master.cfg
> +++ b/master.cfg
> @@ -4,6 +4,7 @@
>  import os
>  import imp
>  import pkg_resources
> +import socket
>
>  from buildbot.plugins import *
>  from buildbot.plugins import db
> @@ -55,6 +56,7 @@ imp.reload(services)
>  imp.reload(www)
>
>  c = BuildmasterConfig = {}
> +url = os.path.join('http://', socket.getfqdn() + ':' + str(config.web_port) 
> + '/')
>
>  # Disable usage reporting
>  c['buildbotNetUsageData'] = None
> @@ -76,6 +78,7 @@ c['www'] = www.www
>  c['workers'] = workers.workers
>
>  c['title'] = "Yocto Autobuilder"
> -c['titleURL'] = "https://autobuilder.yoctoproject.org/main/;
> +c['titleURL'] = url
>  # visible location for internal web server
> -c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
> +# - Default c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
> +c['buildbotURL'] = url

I appreciate what you're trying to do here and make this autoconfigure.
 Unfortunately the urls can't always be figured out this way, the above
for example drops the "/main/" part, without which the autobuilder
won't work. The server can be behind forwarding or proxies/firewalls
which also make this problematic.

I also agree with Martin that using os.path.join() in a url is
incorrect, its not meant for urls.

Most people setting up an autobuilder will need to have some
customisations on top of yocto-autobuilder2, I don't think its possible
to avoid that. I'd therefore perhaps try and concentrate on having key
modules like the lava integration available and accept there will
always be some local configuration the end user needs to make to things
like the URL details? Even the main autobuilder adds in passwords and
some other local config on top of the stardard repo...

Cheers,

Richard

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

Re: [yocto] [PATCH] [yocto-autobuilder] init: Fix the import module yoctoabb & yocto_console_view

[Chan, Aaron Chun Yew]

Hi Richard,

[Richard] I think this means you're using python2 and we really should be using
python3 as I don't want to support both...

[Reply] This error/bug was found during buildbot startup meaning this is out of 
my control. 
Maybe you have a fix for this, otherwise I do suggest to add in 
__init__.py in places where we need to source custom modules.

$ buildbot start ~/yocto-controller
$ cat -n 100 ~/yocto-controller/twistd.log

58002018-07-10 18:42:13+0800 [-] Main loop terminated.
  5801  2018-07-10 18:42:13+0800 [-] Server Shut Down.
  5802  2018-07-10 18:42:27+0800 [-] Loading buildbot.tac...
  5803  2018-07-10 18:42:27+0800 [-] Loaded.
  5804  2018-07-10 18:42:27+0800 [-] twistd 18.4.0 (/usr/bin/python 2.7.13) 
starting up.
  5805  2018-07-10 18:42:27+0800 [-] reactor class: 
twisted.internet.epollreactor.EPollReactor.
  5806  2018-07-10 18:42:27+0800 [-] Starting BuildMaster -- buildbot.version: 
1.2.0
  5807  2018-07-10 18:42:27+0800 [-] Loading configuration from 
'/home/ab/yocto-controller/master.cfg'
  5808  2018-07-10 18:42:27+0800 [-] error while parsing config file:
  5809  Traceback (most recent call last):
  5810File 
"/home/ab/.local/lib/python2.7/site-packages/twisted/python/threadpool.py", 
line 266, in 
  5811  inContext.theWork = lambda: context.call(ctx, func, *args, 
**kw)
  5812File 
"/home/ab/.local/lib/python2.7/site-packages/twisted/python/context.py", line 
122, in callWithContext
  5813  return self.currentContext().callWithContext(ctx, func, 
*args, **kw)
  5814File 
"/home/ab/.local/lib/python2.7/site-packages/twisted/python/context.py", line 
85, in callWithContext
  5815  return func(*args,**kw)
  5816File 
"/home/ab/.local/lib/python2.7/site-packages/buildbot/config.py", line 182, in 
loadConfig
  5817  self.basedir, self.configFileName)
  5818  ---  ---
  5819File 
"/home/ab/.local/lib/python2.7/site-packages/buildbot/config.py", line 140, in 
loadConfigDict
  5820  execfile(filename, localDict)
  5821File 
"/home/ab/.local/lib/python2.7/site-packages/twisted/python/compat.py", line 
246, in execfile
  5822  exec(code, globals, locals)
  5823File "/home/ab/yocto-controller/master.cfg", line 11, in 

  5824  from yoctoabb import builders, config, schedulers, workers, 
services, www
  5825  exceptions.ImportError: No module named yoctoabb
  5826  
  5827  2018-07-10 18:42:27+0800 [-] Configuration Errors:
  5828  2018-07-10 18:42:27+0800 [-]   error while parsing config file: No 
module named yoctoabb (traceback in logfile)
  5829  2018-07-10 18:42:27+0800 [-] Halting master.
  5830  2018-07-10 18:42:27+0800 [-] BuildMaster startup failed
  5831  2018-07-10 18:42:27+0800 [-] BuildMaster is stopped
  5832  2018-07-10 18:42:27+0800 [-] Main loop terminated.
  5833  2018-07-10 18:42:27+0800 [-] Server Shut Down.

Cheers,
Aaron

From: richard.pur...@linuxfoundation.org [richard.pur...@linuxfoundation.org]
Sent: Tuesday, July 10, 2018 4:40 PM
To: Chan, Aaron Chun Yew; yocto@yoctoproject.org; Burton, Ross; Eggleton, Paul
Subject: Re: [PATCH] [yocto-autobuilder] init: Fix the import module yoctoabb & 
yocto_console_view

On Tue, 2018-07-10 at 11:24 +0800, Aaron Chan wrote:
> This patch is to fix the inconsistency in loading custom module
> yoctoabb & yocto_console_view during Buildbot Master startup.
>
> Signed-off-by: Aaron Chan 
> ---
>  __init__.py| 0
>  yocto_console_view/__init__.py | 0
>  2 files changed, 0 insertions(+), 0 deletions(-)
>  create mode 100644 __init__.py
>  create mode 100644 yocto_console_view/__init__.py

I think this means you're using python2 and we really should be using
python3 as I don't want to support both...

Cheers,

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

Re: [yocto] POSIX capability broken pseudo

[Kumar, Shrawan]

Any update  on this ?


Regards
Shrawan

From: Kumar, Shrawan
Sent: 09 July 2018 17:17
To: 'yocto@yoctoproject.org' 
Cc: 'connect.shra...@gmail.com' ; 'Khem Raj' 

Subject: POSIX capability broken pseudo

Hello Team,

Under DISTRO_VERSION = "2.0.2" ("jethro"), I was using the attached 
“setcap.patch” on pseudo_1.7.4  to get POSIX capability set in the files as 
below :

pkg_postinst_${PN}() {

setcap cap_net_raw+ep  $D$bindir/helloworld

}

This was working fine.


However, recently switched to DISTRO_VERSION = "2.2.2" ("morty") - 
pseudo_1.8.1, where the patch is getting applied but the POSIX capabilities are 
not getting set.

Can someone help here?


Regards
Shrawan


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

Re: [linux-yocto] [PATCH] intel-x86: Add intel-x86 BSPs

[Liu, Yongxin]

This is mainly used for Wind River intel-x86 BSP.


Thanks,
Yongxin


-Original Message-
From: Anuj Mittal [mailto:anuj.mit...@intel.com] 
Sent: Tuesday, July 10, 2018 16:53
To: Liu, Yongxin; linux-yocto@yoctoproject.org
Subject: Re: [linux-yocto] [PATCH] intel-x86: Add intel-x86 BSPs

On 07/10/2018 03:52 PM, Yongxin Liu wrote:
> Create intel-x86-32/64 descriptions in yocto-kernel-cache. 
> These BSPs include all the core support for intel-x86 BSP.
> 
> This is an initial step to get the machines available and testing.
> 
> Signed-off-by: Yongxin Liu 
> ---
>  bsp/intel-x86/cfs-bandwidth.cfg |   1 +
>  bsp/intel-x86/intel-x86-32-standard.scc |  10 +
>  bsp/intel-x86/intel-x86-32.cfg  |  23 ++
>  bsp/intel-x86/intel-x86-32.scc  |   6 +
>  bsp/intel-x86/intel-x86-64-standard.scc |   9 +
>  bsp/intel-x86/intel-x86-64.cfg  |  51 
>  bsp/intel-x86/intel-x86-64.scc  |   9 +
>  bsp/intel-x86/intel-x86-acpi.cfg|  16 ++
>  bsp/intel-x86/intel-x86-hugepage.cfg|   2 +
>  bsp/intel-x86/intel-x86-igb-overrides.cfg   |   1 +
>  bsp/intel-x86/intel-x86-ixgbe-overrides.cfg |   1 +
>  bsp/intel-x86/intel-x86-mga.cfg |   3 +
>  bsp/intel-x86/intel-x86.cfg | 370 
> 
>  bsp/intel-x86/intel-x86.scc |  46 
>  14 files changed, 548 insertions(+)
>  create mode 100644 bsp/intel-x86/cfs-bandwidth.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-32-standard.scc
>  create mode 100644 bsp/intel-x86/intel-x86-32.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-32.scc
>  create mode 100644 bsp/intel-x86/intel-x86-64-standard.scc
>  create mode 100644 bsp/intel-x86/intel-x86-64.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-64.scc
>  create mode 100644 bsp/intel-x86/intel-x86-acpi.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-hugepage.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-igb-overrides.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-ixgbe-overrides.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-mga.cfg
>  create mode 100644 bsp/intel-x86/intel-x86.cfg
>  create mode 100644 bsp/intel-x86/intel-x86.scc

I am just curious, how is this different from what is enabled via
intel-common or common-pc?

Thanks,

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

Re: [yocto] [PATCH] [yocto-autobuilder] master.cfg: Defaults autobuilder URL based on FQDN

[Richard Purdie]

On Tue, 2018-07-10 at 11:18 +0800, Aaron Chan wrote:
> This patch is to enable auto-assignments buildbot URL based on Hosts FQDN.
> The socket module allows the retrieval on FQDN and constructs the entire
> URL by default, this default settings can be overwritten in c['buildbotURL']
> based on local administrator preferences.
> 
> Signed-off-by: Aaron Chan 
> ---
>  master.cfg | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/master.cfg b/master.cfg
> index fca80d2..49ddeb4 100644
> --- a/master.cfg
> +++ b/master.cfg
> @@ -4,6 +4,7 @@
>  import os
>  import imp
>  import pkg_resources
> +import socket
>  
>  from buildbot.plugins import *
>  from buildbot.plugins import db
> @@ -55,6 +56,7 @@ imp.reload(services)
>  imp.reload(www)
>  
>  c = BuildmasterConfig = {}
> +url = os.path.join('http://', socket.getfqdn() + ':' + str(config.web_port) 
> + '/')
>  
>  # Disable usage reporting
>  c['buildbotNetUsageData'] = None
> @@ -76,6 +78,7 @@ c['www'] = www.www
>  c['workers'] = workers.workers
>  
>  c['title'] = "Yocto Autobuilder"
> -c['titleURL'] = "https://autobuilder.yoctoproject.org/main/;
> +c['titleURL'] = url
>  # visible location for internal web server
> -c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
> +# - Default c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
> +c['buildbotURL'] = url

I appreciate what you're trying to do here and make this autoconfigure.
 Unfortunately the urls can't always be figured out this way, the above
for example drops the "/main/" part, without which the autobuilder
won't work. The server can be behind forwarding or proxies/firewalls
which also make this problematic.

I also agree with Martin that using os.path.join() in a url is
incorrect, its not meant for urls.

Most people setting up an autobuilder will need to have some
customisations on top of yocto-autobuilder2, I don't think its possible
to avoid that. I'd therefore perhaps try and concentrate on having key
modules like the lava integration available and accept there will
always be some local configuration the end user needs to make to things
like the URL details? Even the main autobuilder adds in passwords and
some other local config on top of the stardard repo...

Cheers,

Richard

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

Re: [linux-yocto] [PATCH] intel-x86: Add intel-x86 BSPs

[Anuj Mittal]

On 07/10/2018 03:52 PM, Yongxin Liu wrote:
> Create intel-x86-32/64 descriptions in yocto-kernel-cache. 
> These BSPs include all the core support for intel-x86 BSP.
> 
> This is an initial step to get the machines available and testing.
> 
> Signed-off-by: Yongxin Liu 
> ---
>  bsp/intel-x86/cfs-bandwidth.cfg |   1 +
>  bsp/intel-x86/intel-x86-32-standard.scc |  10 +
>  bsp/intel-x86/intel-x86-32.cfg  |  23 ++
>  bsp/intel-x86/intel-x86-32.scc  |   6 +
>  bsp/intel-x86/intel-x86-64-standard.scc |   9 +
>  bsp/intel-x86/intel-x86-64.cfg  |  51 
>  bsp/intel-x86/intel-x86-64.scc  |   9 +
>  bsp/intel-x86/intel-x86-acpi.cfg|  16 ++
>  bsp/intel-x86/intel-x86-hugepage.cfg|   2 +
>  bsp/intel-x86/intel-x86-igb-overrides.cfg   |   1 +
>  bsp/intel-x86/intel-x86-ixgbe-overrides.cfg |   1 +
>  bsp/intel-x86/intel-x86-mga.cfg |   3 +
>  bsp/intel-x86/intel-x86.cfg | 370 
> 
>  bsp/intel-x86/intel-x86.scc |  46 
>  14 files changed, 548 insertions(+)
>  create mode 100644 bsp/intel-x86/cfs-bandwidth.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-32-standard.scc
>  create mode 100644 bsp/intel-x86/intel-x86-32.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-32.scc
>  create mode 100644 bsp/intel-x86/intel-x86-64-standard.scc
>  create mode 100644 bsp/intel-x86/intel-x86-64.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-64.scc
>  create mode 100644 bsp/intel-x86/intel-x86-acpi.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-hugepage.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-igb-overrides.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-ixgbe-overrides.cfg
>  create mode 100644 bsp/intel-x86/intel-x86-mga.cfg
>  create mode 100644 bsp/intel-x86/intel-x86.cfg
>  create mode 100644 bsp/intel-x86/intel-x86.scc

I am just curious, how is this different from what is enabled via
intel-common or common-pc?

Thanks,

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

Re: [yocto] SRC_URI git from ssh fails

[Martin Hundebøll]

Hi again,

On 2018-07-10 10:37, Martin Hundebøll wrote:

Hi Mauro,

On 2018-07-10 10:31, Mauro Ziliani wrote:

Hi all

I'm working with Krogoth and imx6dlsabresd board.

I'm in trouble fetching source code from a git repository via ssh.

If I get manually the source codes with

git clone ssh://user@server/repos.git -b 0.4

it works


If I put it in myrecipe_git.bb with


SRC_URI = " \

    git://user@server/repos.git;protocol=ssh;tag=0.4 \

"


You might get lucky with a colon instead of the slash:

     git://user@server:repos.git;protocol=ssh;tag=0.4

But it is just a wild guess, and I didn't really test it :)

// Martin



S="${WORKDIR}/${PN}-${PV}"


the fecth task fails.


I try also SRCREV="0.4" outside SRC_URI and rev=0.4 in place of tag=0.4


Oh, don't base your checkouts on tags, as they can change without 
bitbake noticing.


Put a commit id in SRCREV instead and look into AUTOREV if you need to 
always build the latest and greatest.


// Martin



Where I mistake?


Thanks


MZ






--
Kind regards,
Martin Hundebøll
Embedded Linux Consultant

+45 61 65 54 61
mar...@geanix.com

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

Re: [yocto] [PATCH] [yocto-autobuilder] init: Fix the import module yoctoabb & yocto_console_view

[Richard Purdie]

On Tue, 2018-07-10 at 11:24 +0800, Aaron Chan wrote:
> This patch is to fix the inconsistency in loading custom module
> yoctoabb & yocto_console_view during Buildbot Master startup.
> 
> Signed-off-by: Aaron Chan 
> ---
>  __init__.py| 0
>  yocto_console_view/__init__.py | 0
>  2 files changed, 0 insertions(+), 0 deletions(-)
>  create mode 100644 __init__.py
>  create mode 100644 yocto_console_view/__init__.py

I think this means you're using python2 and we really should be using
python3 as I don't want to support both...

Cheers,

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

Re: [yocto] SRC_URI git from ssh fails

[Martin Hundebøll]

Hi Mauro,

On 2018-07-10 10:31, Mauro Ziliani wrote:

Hi all

I'm working with Krogoth and imx6dlsabresd board.

I'm in trouble fetching source code from a git repository via ssh.

If I get manually the source codes with

git clone ssh://user@server/repos.git -b 0.4

it works


If I put it in myrecipe_git.bb with


SRC_URI = " \

    git://user@server/repos.git;protocol=ssh;tag=0.4 \

"


You might get lucky with a colon instead of the slash:

git://user@server:repos.git;protocol=ssh;tag=0.4

But it is just a wild guess, and I didn't really test it :)

// Martin



S="${WORKDIR}/${PN}-${PV}"


the fecth task fails.


I try also SRCREV="0.4" outside SRC_URI and rev=0.4 in place of tag=0.4


Where I mistake?


Thanks


MZ




--
Kind regards,
Martin Hundebøll
Embedded Linux Consultant

+45 61 65 54 61
mar...@geanix.com

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

[yocto] SRC_URI git from ssh fails

[Mauro Ziliani]

Hi all

I'm working with Krogoth and imx6dlsabresd board.

I'm in trouble fetching source code from a git repository via ssh.

If I get manually the source codes with

git clone ssh://user@server/repos.git -b 0.4

it works


If I put it in myrecipe_git.bb with


SRC_URI = " \

   git://user@server/repos.git;protocol=ssh;tag=0.4 \

"

S="${WORKDIR}/${PN}-${PV}"


the fecth task fails.


I try also SRCREV="0.4" outside SRC_URI and rev=0.4 in place of tag=0.4


Where I mistake?


Thanks


MZ


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

Re: [yocto] Keeping and modifying Source code in Yocto

[ChenQi]

On 07/10/2018 02:18 PM, Paul Eggleton wrote:

On Tuesday, 10 July 2018 3:32:56 AM CEST ChenQi wrote:

I usually use the following steps when I need to modify source for some
purpose.

1. bitbake A (or at least bitbake A -c configure)
*2. cd tmp/work/x/A/**
**3. make the modification*
4. bitbake A -c compile -f
5. bitbake A

If you find the modification useful, make a patch from it.

This is the old way of doing it which can under some circumstances result in
you losing your changes to the source tree, since the sources under tmp/work/
are only ever intended to be there temporarily. Devtool (as recommend by
others on this thread) is designed to enable this workflow in a much safer
manner.

Cheers,
Paul


Thanks Paul. I'll turn to use devtool.

Best Regards,

Chen Qi

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

[linux-yocto] [PATCH] intel-x86: Add intel-x86 BSPs

[Yongxin Liu]

Create intel-x86-32/64 descriptions in yocto-kernel-cache. 
These BSPs include all the core support for intel-x86 BSP.

This is an initial step to get the machines available and testing.

Signed-off-by: Yongxin Liu 
---
 bsp/intel-x86/cfs-bandwidth.cfg |   1 +
 bsp/intel-x86/intel-x86-32-standard.scc |  10 +
 bsp/intel-x86/intel-x86-32.cfg  |  23 ++
 bsp/intel-x86/intel-x86-32.scc  |   6 +
 bsp/intel-x86/intel-x86-64-standard.scc |   9 +
 bsp/intel-x86/intel-x86-64.cfg  |  51 
 bsp/intel-x86/intel-x86-64.scc  |   9 +
 bsp/intel-x86/intel-x86-acpi.cfg|  16 ++
 bsp/intel-x86/intel-x86-hugepage.cfg|   2 +
 bsp/intel-x86/intel-x86-igb-overrides.cfg   |   1 +
 bsp/intel-x86/intel-x86-ixgbe-overrides.cfg |   1 +
 bsp/intel-x86/intel-x86-mga.cfg |   3 +
 bsp/intel-x86/intel-x86.cfg | 370 
 bsp/intel-x86/intel-x86.scc |  46 
 14 files changed, 548 insertions(+)
 create mode 100644 bsp/intel-x86/cfs-bandwidth.cfg
 create mode 100644 bsp/intel-x86/intel-x86-32-standard.scc
 create mode 100644 bsp/intel-x86/intel-x86-32.cfg
 create mode 100644 bsp/intel-x86/intel-x86-32.scc
 create mode 100644 bsp/intel-x86/intel-x86-64-standard.scc
 create mode 100644 bsp/intel-x86/intel-x86-64.cfg
 create mode 100644 bsp/intel-x86/intel-x86-64.scc
 create mode 100644 bsp/intel-x86/intel-x86-acpi.cfg
 create mode 100644 bsp/intel-x86/intel-x86-hugepage.cfg
 create mode 100644 bsp/intel-x86/intel-x86-igb-overrides.cfg
 create mode 100644 bsp/intel-x86/intel-x86-ixgbe-overrides.cfg
 create mode 100644 bsp/intel-x86/intel-x86-mga.cfg
 create mode 100644 bsp/intel-x86/intel-x86.cfg
 create mode 100644 bsp/intel-x86/intel-x86.scc

diff --git a/bsp/intel-x86/cfs-bandwidth.cfg b/bsp/intel-x86/cfs-bandwidth.cfg
new file mode 100644
index ..0be30bfd
--- /dev/null
+++ b/bsp/intel-x86/cfs-bandwidth.cfg
@@ -0,0 +1 @@
+CONFIG_CFS_BANDWIDTH=y
diff --git a/bsp/intel-x86/intel-x86-32-standard.scc 
b/bsp/intel-x86/intel-x86-32-standard.scc
new file mode 100644
index ..3232b76f
--- /dev/null
+++ b/bsp/intel-x86/intel-x86-32-standard.scc
@@ -0,0 +1,10 @@
+define KMACHINE intel-x86-32
+define KTYPE standard
+define KARCH x86
+
+include ktypes/standard
+branch intel-x86
+
+include intel-x86-32.scc
+kconf hardware intel-x86-hugepage.cfg
+kconf hardware cfs-bandwidth.cfg
diff --git a/bsp/intel-x86/intel-x86-32.cfg b/bsp/intel-x86/intel-x86-32.cfg
new file mode 100644
index ..1f5800d3
--- /dev/null
+++ b/bsp/intel-x86/intel-x86-32.cfg
@@ -0,0 +1,23 @@
+#.
+#WARNING
+#
+# This file is a kernel configuration fragment, and not a full kernel
+# configuration file.  The final kernel configuration is made up of
+# an assembly of processed fragments, each of which is designed to
+# capture a specific part of the final configuration (e.g. platform
+# configuration, feature configuration, and board specific hardware
+# configuration).  For more information on kernel configuration, please
+# consult the product documentation.
+#
+#.
+
+# Switch back to x86-32 from x86-64
+CONFIG_X86_32=y
+# CONFIG_64BIT is not set
+
+#
+# Processor type and features
+#
+CONFIG_X86_BIGSMP=y
+CONFIG_X86_GENERIC=y
+CONFIG_HIGHMEM64G=y
diff --git a/bsp/intel-x86/intel-x86-32.scc b/bsp/intel-x86/intel-x86-32.scc
new file mode 100644
index ..b1d48495
--- /dev/null
+++ b/bsp/intel-x86/intel-x86-32.scc
@@ -0,0 +1,6 @@
+# Core configuration settings for x86-32
+include cfg/x86.scc nopatch
+
+include intel-x86.scc
+
+kconf hardware intel-x86-32.cfg
diff --git a/bsp/intel-x86/intel-x86-64-standard.scc 
b/bsp/intel-x86/intel-x86-64-standard.scc
new file mode 100644
index ..e22e6232
--- /dev/null
+++ b/bsp/intel-x86/intel-x86-64-standard.scc
@@ -0,0 +1,9 @@
+define KMACHINE intel-x86-64
+define KTYPE standard
+define KARCH x86
+
+include ktypes/standard
+
+include intel-x86-64.scc
+kconf hardware intel-x86-hugepage.cfg
+kconf hardware cfs-bandwidth.cfg
diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-64.cfg
new file mode 100644
index ..4e8a4d78
--- /dev/null
+++ b/bsp/intel-x86/intel-x86-64.cfg
@@ -0,0 +1,51 @@
+#
+# Memory power savings
+#
+CONFIG_I7300_IDLE=m
+
+#
+# ACPI NUMA
+#
+CONFIG_X86_64_ACPI_NUMA=y
+CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
+CONFIG_CRYPTO_AES_X86_64=m
+CONFIG_CRYPTO_SHA1_SSSE3=m
+CONFIG_CRYPTO_SHA256_SSSE3=m
+CONFIG_CRYPTO_SHA512_SSSE3=m
+
+# EDAC
+CONFIG_EDAC=y
+CONFIG_EDAC_MM_EDAC=m
+CONFIG_EDAC_DEBUG=y
+CONFIG_EDAC_SBRIDGE=m
+CONFIG_ACPI_APEI=y
+CONFIG_ACPI_APEI_EINJ=m
+CONFIG_ACPI_APEI_GHES=y
+CONFIG_EDAC_PND2=m
+CONFIG_EDAC_SKX=m
+
+
+# ISH
+CONFIG_INTEL_ISH_HID=m
+
+# QAT
+CONFIG_PCI_IOV=y
+#
+# For Linux Kernel Crypto Framework Sample Driver module over QAT.
+#

Re: [yocto] [PATCH] [yocto-autobuilder] master.cfg: Defaults autobuilder URL based on FQDN

[Chan, Aaron Chun Yew]

Hi Martin,

My initial concern was that `os.path.join()` was meant for OS
independent path concatenation, and not constructing URLs.

My two first points still stand, though... Why not just
string-concatenate the separate parts; i.e.

url = 'http://' + socket.getfqdn() + ':' + str(config.web_port) + '/'

[Reply] You have a valid point, however in this case seems like os.path.join() 
doesn't seem to construct a path. It's a bug. 
Will send a new patch on this one. Thanks for reviewing it.

Cheers,
Aaron

From: Martin Hundebøll [mar...@geanix.com]
Sent: Tuesday, July 10, 2018 3:14 PM
To: Chan, Aaron Chun Yew; richard.pur...@linuxfoundation.org; 
yocto@yoctoproject.org; Burton, Ross; Eggleton, Paul
Subject: Re: [yocto] [PATCH] [yocto-autobuilder] master.cfg: Defaults 
autobuilder URL based on FQDN

Hi Aaron,

On 2018-07-10 08:59, Chan, Aaron Chun Yew wrote:
> My name is Aaron and not Aron for start

Sorry about that.

> Martin,
>
> Please try this
>
> #!/usr/bin/env python2
>
> import os
>
> a = os.path.join('http://', 'alibaba.com')
> b = '/'.join(['http://', 'alibaba.com'])
> c = '/'.join(['http:/', 'alibaba.com', ''])
>
> print(a)
> print(b)
> print(c)
>
> and repeat the same for python3, I got the following results:
>
> http://alibaba.com
> http:///alibaba.com
> http://alibaba.com/

I see, thanks for clarifying.

My initial concern was that `os.path.join()` was meant for OS
independent path concatenation, and not constructing URLs.

My two first points still stand, though... Why not just
string-concatenate the separate parts; i.e.

url = 'http://' + socket.getfqdn() + ':' + str(config.web_port) + '/'

But I won't stand in the way of the patch for such a stylish point, so
feel free to ignore it :)

// Martin

> Cheers,
> Aaron
> 
> From: Martin Hundebøll [mar...@geanix.com]
> Sent: Tuesday, July 10, 2018 2:10 PM
> To: Chan, Aaron Chun Yew; richard.pur...@linuxfoundation.org; 
> yocto@yoctoproject.org; Burton, Ross; Eggleton, Paul
> Subject: Re: [yocto] [PATCH] [yocto-autobuilder] master.cfg: Defaults 
> autobuilder URL based on FQDN
>
> Hi Aron,
>
> On 2018-07-10 05:18, Aaron Chan wrote:
>> This patch is to enable auto-assignments buildbot URL based on Hosts FQDN.
>> The socket module allows the retrieval on FQDN and constructs the entire
>> URL by default, this default settings can be overwritten in c['buildbotURL']
>> based on local administrator preferences.
>>
>> Signed-off-by: Aaron Chan 
>> ---
>>master.cfg | 7 +--
>>1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/master.cfg b/master.cfg
>> index fca80d2..49ddeb4 100644
>> --- a/master.cfg
>> +++ b/master.cfg
>> @@ -4,6 +4,7 @@
>>import os
>>import imp
>>import pkg_resources
>> +import socket
>>
>>from buildbot.plugins import *
>>from buildbot.plugins import db
>> @@ -55,6 +56,7 @@ imp.reload(services)
>>imp.reload(www)
>>
>>c = BuildmasterConfig = {}
>> +url = os.path.join('http://', socket.getfqdn() + ':' + str(config.web_port) 
>> + '/')
>
> Why use `os.path.join()` here? It isn't supposed to be used to construct
> url's, and is overkill for this case, and you'd end up with "http:///...;.
>
> // Martin
>
>>
>># Disable usage reporting
>>c['buildbotNetUsageData'] = None
>> @@ -76,6 +78,7 @@ c['www'] = www.www
>>c['workers'] = workers.workers
>>
>>c['title'] = "Yocto Autobuilder"
>> -c['titleURL'] = "https://autobuilder.yoctoproject.org/main/;
>> +c['titleURL'] = url
>># visible location for internal web server
>> -c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
>> +# - Default c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
>> +c['buildbotURL'] = url
>>
>
> --
> Kind regards,
> Martin Hundebøll
> Embedded Linux Consultant
>
> +45 61 65 54 61
> mar...@geanix.com
>
> Geanix IVS
> DK39600706
>

--
Kind regards,
Martin Hundebøll
Embedded Linux Consultant

+45 61 65 54 61
mar...@geanix.com

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

Re: [yocto] [PATCH] [yocto-autobuilder] master.cfg: Defaults autobuilder URL based on FQDN

[Martin Hundebøll]

Hi Aaron,

On 2018-07-10 08:59, Chan, Aaron Chun Yew wrote:

My name is Aaron and not Aron for start


Sorry about that.


Martin,

Please try this

#!/usr/bin/env python2

import os

a = os.path.join('http://', 'alibaba.com')
b = '/'.join(['http://', 'alibaba.com'])
c = '/'.join(['http:/', 'alibaba.com', ''])

print(a)
print(b)
print(c)

and repeat the same for python3, I got the following results:

http://alibaba.com
http:///alibaba.com
http://alibaba.com/


I see, thanks for clarifying.

My initial concern was that `os.path.join()` was meant for OS 
independent path concatenation, and not constructing URLs.


My two first points still stand, though... Why not just 
string-concatenate the separate parts; i.e.


url = 'http://' + socket.getfqdn() + ':' + str(config.web_port) + '/'

But I won't stand in the way of the patch for such a stylish point, so 
feel free to ignore it :)


// Martin


Cheers,
Aaron

From: Martin Hundebøll [mar...@geanix.com]
Sent: Tuesday, July 10, 2018 2:10 PM
To: Chan, Aaron Chun Yew; richard.pur...@linuxfoundation.org; 
yocto@yoctoproject.org; Burton, Ross; Eggleton, Paul
Subject: Re: [yocto] [PATCH] [yocto-autobuilder] master.cfg: Defaults 
autobuilder URL based on FQDN

Hi Aron,

On 2018-07-10 05:18, Aaron Chan wrote:

This patch is to enable auto-assignments buildbot URL based on Hosts FQDN.
The socket module allows the retrieval on FQDN and constructs the entire
URL by default, this default settings can be overwritten in c['buildbotURL']
based on local administrator preferences.

Signed-off-by: Aaron Chan 
---
   master.cfg | 7 +--
   1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/master.cfg b/master.cfg
index fca80d2..49ddeb4 100644
--- a/master.cfg
+++ b/master.cfg
@@ -4,6 +4,7 @@
   import os
   import imp
   import pkg_resources
+import socket

   from buildbot.plugins import *
   from buildbot.plugins import db
@@ -55,6 +56,7 @@ imp.reload(services)
   imp.reload(www)

   c = BuildmasterConfig = {}
+url = os.path.join('http://', socket.getfqdn() + ':' + str(config.web_port) + 
'/')


Why use `os.path.join()` here? It isn't supposed to be used to construct
url's, and is overkill for this case, and you'd end up with "http:///...;.

// Martin



   # Disable usage reporting
   c['buildbotNetUsageData'] = None
@@ -76,6 +78,7 @@ c['www'] = www.www
   c['workers'] = workers.workers

   c['title'] = "Yocto Autobuilder"
-c['titleURL'] = "https://autobuilder.yoctoproject.org/main/;
+c['titleURL'] = url
   # visible location for internal web server
-c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
+# - Default c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
+c['buildbotURL'] = url



--
Kind regards,
Martin Hundebøll
Embedded Linux Consultant

+45 61 65 54 61
mar...@geanix.com

Geanix IVS
DK39600706



--
Kind regards,
Martin Hundebøll
Embedded Linux Consultant

+45 61 65 54 61
mar...@geanix.com

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

Re: [yocto] [PATCH] [yocto-autobuilder] master.cfg: Defaults autobuilder URL based on FQDN

[Chan, Aaron Chun Yew]

My name is Aaron and not Aron for start

Martin,

Please try this

#!/usr/bin/env python2

import os

a = os.path.join('http://', 'alibaba.com')
b = '/'.join(['http://', 'alibaba.com'])
c = '/'.join(['http:/', 'alibaba.com', ''])

print(a)
print(b)
print(c)

and repeat the same for python3, I got the following results:

http://alibaba.com
http:///alibaba.com
http://alibaba.com/

Cheers,
Aaron

From: Martin Hundebøll [mar...@geanix.com]
Sent: Tuesday, July 10, 2018 2:10 PM
To: Chan, Aaron Chun Yew; richard.pur...@linuxfoundation.org; 
yocto@yoctoproject.org; Burton, Ross; Eggleton, Paul
Subject: Re: [yocto] [PATCH] [yocto-autobuilder] master.cfg: Defaults 
autobuilder URL based on FQDN

Hi Aron,

On 2018-07-10 05:18, Aaron Chan wrote:
> This patch is to enable auto-assignments buildbot URL based on Hosts FQDN.
> The socket module allows the retrieval on FQDN and constructs the entire
> URL by default, this default settings can be overwritten in c['buildbotURL']
> based on local administrator preferences.
>
> Signed-off-by: Aaron Chan 
> ---
>   master.cfg | 7 +--
>   1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/master.cfg b/master.cfg
> index fca80d2..49ddeb4 100644
> --- a/master.cfg
> +++ b/master.cfg
> @@ -4,6 +4,7 @@
>   import os
>   import imp
>   import pkg_resources
> +import socket
>
>   from buildbot.plugins import *
>   from buildbot.plugins import db
> @@ -55,6 +56,7 @@ imp.reload(services)
>   imp.reload(www)
>
>   c = BuildmasterConfig = {}
> +url = os.path.join('http://', socket.getfqdn() + ':' + str(config.web_port) 
> + '/')

Why use `os.path.join()` here? It isn't supposed to be used to construct
url's, and is overkill for this case, and you'd end up with "http:///...;.

// Martin

>
>   # Disable usage reporting
>   c['buildbotNetUsageData'] = None
> @@ -76,6 +78,7 @@ c['www'] = www.www
>   c['workers'] = workers.workers
>
>   c['title'] = "Yocto Autobuilder"
> -c['titleURL'] = "https://autobuilder.yoctoproject.org/main/;
> +c['titleURL'] = url
>   # visible location for internal web server
> -c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
> +# - Default c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
> +c['buildbotURL'] = url
>

--
Kind regards,
Martin Hundebøll
Embedded Linux Consultant

+45 61 65 54 61
mar...@geanix.com

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

Re: [yocto] Keeping and modifying Source code in Yocto

[Paul Eggleton]

On Tuesday, 10 July 2018 3:32:56 AM CEST ChenQi wrote:
> I usually use the following steps when I need to modify source for some 
> purpose.
> 
> 1. bitbake A (or at least bitbake A -c configure)
> *2. cd tmp/work/x/A/**
> **3. make the modification*
> 4. bitbake A -c compile -f
> 5. bitbake A
> 
> If you find the modification useful, make a patch from it.

This is the old way of doing it which can under some circumstances result in 
you losing your changes to the source tree, since the sources under tmp/work/ 
are only ever intended to be there temporarily. Devtool (as recommend by 
others on this thread) is designed to enable this workflow in a much safer 
manner.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

[yocto] QA cycle report for 2.3.4 RC1

[Yeoh, Ee Peng]

Hello All,



This is the full report for 2.3.4.rc1:

https://wiki.yoctoproject.org/wiki/WW25_-_2018-06-22-_Full_Test_Cycle_-_2.3.4_rc1



=== Summary 



All planned tests were executed.  There were zero high milestone defect.  Team 
had found 3 new defects where yocto-bsp failed to create bootable image with 
new bsp layer [1], QEMU ended unexpectedly during 
do_testimage:core-image-lsb-sdk [2], & valgrind ptest passed in 2.3.3.rc1 
failed at current release [3].



=== QA-Hints



Found 3 non critical defects.



=== Bugs 



New Bugs

[1] Bug 12846 - [QA 2.3.4rc1][Meta-Yocto][Case 309, Case 310]: After creating 
BSP layer using yocto-bsp, the image created not able to boot up as local 
variable 'qbsys' referenced before assignment

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12846



[2] Bug 12812 - [2.3.4 rc1] Qemu ended unexpectedly during 
do_testimage:core-image-lsb-sdk

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12812



[3] Bug 12847 - [2.3.4 rc1] valgrind ptest failed

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12847



Regards

Ee Peng

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

Re: [yocto] [PATCH] [yocto-autobuilder] master.cfg: Defaults autobuilder URL based on FQDN

[Martin Hundebøll]

Hi Aron,

On 2018-07-10 05:18, Aaron Chan wrote:

This patch is to enable auto-assignments buildbot URL based on Hosts FQDN.
The socket module allows the retrieval on FQDN and constructs the entire
URL by default, this default settings can be overwritten in c['buildbotURL']
based on local administrator preferences.

Signed-off-by: Aaron Chan 
---
  master.cfg | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/master.cfg b/master.cfg
index fca80d2..49ddeb4 100644
--- a/master.cfg
+++ b/master.cfg
@@ -4,6 +4,7 @@
  import os
  import imp
  import pkg_resources
+import socket
  
  from buildbot.plugins import *

  from buildbot.plugins import db
@@ -55,6 +56,7 @@ imp.reload(services)
  imp.reload(www)
  
  c = BuildmasterConfig = {}

+url = os.path.join('http://', socket.getfqdn() + ':' + str(config.web_port) + 
'/')


Why use `os.path.join()` here? It isn't supposed to be used to construct 
url's, and is overkill for this case, and you'd end up with "http:///...;.


// Martin

  
  # Disable usage reporting

  c['buildbotNetUsageData'] = None
@@ -76,6 +78,7 @@ c['www'] = www.www
  c['workers'] = workers.workers
  
  c['title'] = "Yocto Autobuilder"

-c['titleURL'] = "https://autobuilder.yoctoproject.org/main/;
+c['titleURL'] = url
  # visible location for internal web server
-c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
+# - Default c['buildbotURL'] = "https://autobuilder.yoctoproject.org/main/;
+c['buildbotURL'] = url



--
Kind regards,
Martin Hundebøll
Embedded Linux Consultant

+45 61 65 54 61
mar...@geanix.com

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

Re: [yocto] Any Linux/Yocto Image Installer (for target system)

[Raymond Yeung]

Thanks Ross.  I found init-install.sh that I could relate to run-time 
installation offered at BOOT time.  And I'd used it to install image on SSD 
from USB drive.


Would you or anyone know where the script that formats/generates .hddimg?  I'd 
like to see if we could customize the layout of this image to multiple 
partitions.  The reason I'm thinking this way is that our real H/W (vs. the 
evaluation platform I've been using) doesn't support USB port, thus no run-time 
installer.



From: Burton, Ross 
Sent: Monday, July 9, 2018 2:02 AM
To: Raymond Yeung
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Any Linux/Yocto Image Installer (for target system)

The relevant recipes are in meta/recipes-core/initrdscripts/.

Ross

On 9 July 2018 at 04:10, Raymond Yeung 
mailto:rksye...@hotmail.com>> wrote:

This brings up the next logical question - where is the installer?  I'd already 
done a grep and looked into the volume of output.  You could ask why don't I 
read the code.  Yes, only if I know what I'm reading is the "correct" 
file/code.  Otherwise, I could be spending a lot of time reading a lot of 
unrelated codes.


If I did "dd" of .hddimg to SSD, there's only 1 partition.  If I could locate 
where the logic is that generates this .hddimg file, perhaps I could figure out 
how it creates its single partition, and perhaps add one or more partitions to 
it as well.



From: Burton, Ross mailto:ross.bur...@intel.com>>
Sent: Saturday, July 7, 2018 3:39 PM
To: Raymond Yeung
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Any Linux/Yocto Image Installer (for target system)

The easiest thing would be to edit the installer script that goes into
the hddimg to create your extra partitions and whatever else you want
done.

Ross

On 6 July 2018 at 22:52, Raymond Yeung 
mailto:rksye...@hotmail.com>> wrote:
> Is there any installer that I could download along with the .hddimg (or
> .iso) image to the RAM, invoke the installer, so we could have a bootable
> image installed on a SSD?
>
>
> History:
>
> I can already create USB live image with dd and .hddimg.  I could also dd
> the .hddimg onto SSD and make it bootable.  The problem is that I need
> multiple partitions on my 250MB SSD, some reserved for other purposes.
>
>
> I find that when booting up with USB running SysLinux, I could install GRUB,
> vmlinuz, along with boot.img and core.img under /boot directory, and the
> rootFs under root (i.e. '/') directory.  That's 4 partitions.  I believe I
> could resize the largest partition after installation to do what I want.
>
>
> Is there a way to do this manually, possibly with a utility or a shell
> script?
>
>
> Thanks,
>
> Raymond
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions. 
Subscribe before posting to bypass moderation.



>

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