Re: [yocto] #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image

2020-09-29 Thread Khem Raj
what all functionality are you looking for. E.g. there is date utility
and hwclock  utility which can help you manipulate system time. you
could also look into ntpd and/or chrony for Network time setting etc.

On Tue, Sep 29, 2020 at 11:05 AM Monsees, Steven C (US) via
lists.yoctoproject.org
 wrote:
>
>
> Currently not using system as our default init system (investigating why but 
> this might not be an option).
>
> Is there any other utility I might use under Yocto to get similar data as 
> that produced by timedatectl ?
>
> Thanks,
> Steve
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50887): https://lists.yoctoproject.org/g/yocto/message/50887
Mute This Topic: https://lists.yoctoproject.org/mt/77180295/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #systemd:https://lists.yoctoproject.org/g/yocto/mutehashtag/systemd
Mute #linux:https://lists.yoctoproject.org/g/yocto/mutehashtag/linux
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] OpenEmbedded Happy Hour September 30 9pm/2100 UTC

2020-09-29 Thread Denys Dmytriyenko
Just a reminder about our upcoming OpenEmbedded Happy Hour on September 30 for 
Oceania/Asia timezones @ 2100/9pm UTC (5pm EDT):

https://www.openembedded.org/wiki/Calendar
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+September+30=20200930T21

-- 
Denys

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50886): https://lists.yoctoproject.org/g/yocto/message/50886
Mute This Topic: https://lists.yoctoproject.org/mt/77208513/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [PATCH yocto-autobuilder-helper] config.json: QAMAIL_CC => qa-build-notification

2020-09-29 Thread Tim Orling
From: Tim Orling 

Replace the hard-coded individual email addresses with
the mailing list created for this purpose:

qa-build-notificat...@lists.yoctoproject.org

Signed-off-by: Tim Orling 
---
 config.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 9d66d48..d65c0f4 100644
--- a/config.json
+++ b/config.json
@@ -16,7 +16,7 @@
 "TRASH_DIR" : "${BASE_HOMEDIR}/git/trash",
 
 "QAMAIL_TO" : "yocto@lists.yoctoproject.org",
-"QAMAIL_CC" : "ota...@ossystems.com.br, yi.z...@windriver.com, 
apoorv.san...@intel.com, ee.peng.y...@intel.com, aaron.chun.yew.c...@intel.com, 
richard.pur...@linuxfoundation.org, akuster...@gmail.com, 
sjolley.yp...@gmail.com, sangeeta.j...@intel.com",
+"QAMAIL_CC" : "qa-build-notificat...@lists.yoctoproject.org",
 "WEBPUBLISH_DIR" : "${BASE_SHAREDDIR}/",
 "WEBPUBLISH_URL" : "https://autobuilder.yocto.io/;,
 
-- 
2.25.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50885): https://lists.yoctoproject.org/g/yocto/message/50885
Mute This Topic: https://lists.yoctoproject.org/mt/77206026/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Yocto Technical Team Minutes, Engineering Sync, for September 29, 2020

2020-09-29 Thread Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for September 29, 2020
archive: 
https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolly, Saul Wold, Armin Kuster, Richard Purdie,
Bruce Ashfield, Jon Mason, Michael Halstead, David Reyna, Jeremy Puhlman,
Jan-Simon Möller, Ross Burton, Paul Barker, Scott Murray, Tim Orling,
Steve Sakoman, Randy MacLeod, , Alejandro H

== notes ==
- M3-rc2 through QA, release for later this week
- 3.1.3 in QA, release Thur or Fri this week
- more AB issues resolved, but many remain
- --x corruption in pseudo, probably undetected in many cases

== general ==
RP: 2 of 5 bugs fixed against M3-rc1, so we’re ready to move on

RP: the pseudo issue explains strange bugs we’ve seen over the years
Randy: any solutions?
RP: seems worrying, Peter thinks it should abort. with the aborts it only gets
through 2-3 tasks before aborting
PaulB: can we do something when non-pseudo tries to touch these paths?
RP: pseudo assumes it has 100% access to the entire system, but there are
things we change outside pseudo (which are fine), so we need a patch to
tell pseudo to restrict what it can see, but the ignore-list isn’t
complete. e.g. pseudo and qemu don’t get along so we stop pseudo to run
qemu, qemu then touches files that pseudo controls, but we can’t tell
which files were touched

RP: despite all the changes we’ve made, we’re still seeing timeout issues
on the AB

ScottM: could we scan a set of directories
RP: we could do an integrity check, the problem is deciding when to do it.
there are a number of tasks that run in parallel, so the trick is figuring
out when to do the integrity check.
ScottM: how amenable is that to someone helping without deep knowledge of
pseudo?
RP: once it’s down to analysing individual changes, we should be fine
ScottM: do we need a failed build to work on?
RP: no, with the aborts in place the issues crop up quickly
J-SM: could the abort patch be made available conditionally so people can dig
in?
RP: possibly. the build dies very quickly with the patch, so if we can get to
a certain point before failing then others can jump in
PaulB: other distros use fakeroot, is it worth looking elsewhere for ideas?
RP: we use pseudo because fakeroot had massive issues that didn’t map well
to what we’re doing (not sure if these have all been addressed) e.g. if
you open a shell and do the whole build sequentially in that one shell,
then fakeroot will work fine. but with us we use different tasks, in
parallel, etc which fakeroot doesn’t support
RP: these issues tend to only appear because of the heavy heavy load of the
build servers, these most likely won’t affect people doing “normal”
builds on mostly not-overloaded systems. i.e. the inodes are re-used very
quickly on our AB infrastructure

RP: i have some patches in master-next which i’ll push later this week. but
it raises the question about what to do regarding -stable
J-SM: i suggest doing the same, make the patch optionally available
RP: i’ll try to get it working somewhat so others can jump in more easily
Randy: things generally look good
RP: i think this bug’s been here a long time, but was exacerbated by
recipe-specific sysroots, these generate a *tonne* of database entries
RP: the only way people might have noticed this in the past is if someone did
a binary compare
Randy: right, but nobody’s complained about /bin/ls not having --x (for
example)
Jeremy: i’m guessing the issue has been around since 2.4 (Rocko). we have
been seeing issues where random executables would be missing --x
PaulB: we have to make sure to not attribute this issue to too many bugs

PaulB: Randy and i emailed the maintainers of meta-rust to bring rust support
in during the next development cycle. looks good so far
Randy: i have a patch
PaulB: and the patch adds the fetcher into bitbake

TW: OE happy hour tomorrow

TW: there was a discussion re default values, any resolution?
RP: nobody liked any of the suggestions well enough, so it faded

PaulB: inclusive language: add to contribution guidelines? the contributing
guideline only appears in the wiki, should we have something at the
top-level of the repository?
RP: go for it, anything to help new users

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50884): https://lists.yoctoproject.org/g/yocto/message/50884
Mute This Topic: https://lists.yoctoproject.org/mt/77205410/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] devtool fails on unpack of u-boot-ti-staging and u-boot

2020-09-29 Thread Donald Usry
Using 'devtool modify u-boot-ti-staging' fails on do_unpack with "Exception: 
ModuleNotFoundError: No module named '_sysconfigdata'". I pulled a fresh copy 
of Poky and tried 'devtool modify u-boot' with the default machine and the same 
exception occurs. I have tried others. Performing 'devtool modify 
linux-ti-staging' yields no issues.

Build Configuration:
BB_VERSION   = "1.46.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "arm-poky-linux-gnueabi"
MACHINE  = "am335x-evm"
DISTRO   = "poky"
DISTRO_VERSION   = "3.1.3"
TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard"
TARGET_FPU   = "hard"

meta
meta-poky= "dunfell:012ad10a89a889c21e67c27dc37d22520212548f"
meta-ti  = "master:2e95912f57a66a6a6879b053ba08faec5a6e4500"
meta-arm
meta-arm-toolchain   = "dunfell:c4f04f3fb66f8f4365b08b553af8206372e90a63"
workspace= "dunfell:012ad10a89a889c21e67c27dc37d22520212548f"

Initialising tasks: 100% 
|##|
 Time: 0:00:00
Sstate summary: Wanted 0 Found 0 Missed 0 Current 20 (0% match, 100% complete)
NOTE: Executing Tasks
ERROR: Error executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
*** 0002:devtool_post_unpack(d)
 0003:
File: '/home/dusry/workspace/poky/meta/classes/devtool-source.bbclass', lineno: 
68, function: devtool_post_unpack
 0064:}
 0065:
 0066:
 0067:python devtool_post_unpack() {
*** 0068:import oe.recipeutils
 0069:import shutil
 0070:sys.path.insert(0, os.path.join(d.getVar('COREBASE'), 'scripts', 
'lib'))
 0071:import scriptutils
 0072:from devtool import setup_git_repo
File: '/home/dusry/workspace/poky/meta/lib/oe/recipeutils.py', lineno: 21, 
function: 
 0017:import shutil
 0018:import re
 0019:import fnmatch
 0020:import glob
*** 0021:import bb.tinfoil
 0022:
 0023:from collections import OrderedDict, defaultdict
 0024:from bb.utils import vercmp_string
 0025:
File: '/home/dusry/workspace/poky/bitbake/lib/bb/tinfoil.py', lineno: 19, 
function: 
 0015:from collections import OrderedDict, defaultdict
 0016:from functools import partial
 0017:
 0018:import bb.cache
*** 0019:import bb.cooker
 0020:import bb.providers
 0021:import bb.taskdata
 0022:import bb.utils
 0023:import bb.command
File: '/home/dusry/workspace/poky/bitbake/lib/bb/cooker.py', lineno: 25, 
function: 
 0021:import bb, bb.exceptions, bb.command
 0022:from bb import utils, data, parse, event, cache, providers, taskdata, 
runqueue, build
 0023:import queue
 0024:import signal
*** 0025:import prserv.serv
 0026:import pyinotify
 0027:import json
 0028:import pickle
 0029:import codecs
File: '/home/dusry/workspace/poky/bitbake/lib/prserv/serv.py', lineno: 7, 
function: 
 0003:#
 0004:
 0005:import os,sys,logging
 0006:import signal, time
*** 0007:from xmlrpc.server import SimpleXMLRPCServer, 
SimpleXMLRPCRequestHandler
 0008:import threading
 0009:import queue
 0010:import socket
 0011:import io
File: '/usr/lib/python3.8/xmlrpc/server.py', lineno: 117, function: 
 0113:import socketserver
 0114:import sys
 0115:import os
 0116:import re
*** 0117:import pydoc
 0118:import traceback
 0119:try:
 0120:import fcntl
 0121:except ImportError:
File: '/usr/lib/python3.8/pydoc.py', lineno: 370, function: 
 0366:return module
 0367:
 0368:#  formatter base 
class
 0369:
*** 0370:class Doc:
 0371:
 0372:PYTHONDOCS = os.environ.get("PYTHONDOCS",
 0373:
"https://docs.python.org/%d.%d/library"
 0374:% sys.version_info[:2])
File: '/usr/lib/python3.8/pydoc.py', lineno: 400, function: Doc
 0396:raise TypeError(message)
 0397:
 0398:docmodule = docclass = docroutine = docother = docproperty = 
docdata = fail
 0399:
*** 0400:def getdocloc(self, object, basedir=sysconfig.get_path('stdlib')):
 0401:"""Return the location of module docs or None"""
 0402:
 0403:try:
 0404:file = inspect.getabsfile(object)
File: '/usr/lib/python3.8/sysconfig.py', lineno: 512, function: get_path
 0508:"""Return a path corresponding to the scheme.
 0509:
 0510:``scheme`` is the install scheme name.
 0511:"""
*** 0512:return get_paths(scheme, vars, expand)[name]
 0513:
 0514:
 0515:def 

[yocto] [meta-virtualization] How to enable libvirt to work with XEN on a custom board. #yocto #meta-virtualization

2020-09-29 Thread daparrag via lists.yoctoproject.org
Dear all,

In the past days I was looking for some documentation that allows me to enable 
libvirt to work with xen. In my current implementation I managed to run XEN on 
DOM0 but unluckly I am having problems to make it works with libvirt.
I had followed all the recommendations listed on 
http://git.yoctoproject.org/cgit.cgi/meta-virtualization/tree/README but 
nothing works for me.

when I added libvirt in my packages I got the same error discribed on : 
https://www.yoctoproject.org/pipermail/meta-virtualization/2016-March/001835.html

any Idea of how can I enable libvirt to work with xen?
do you have some .bbappend that works out of the box?

Please let me know.

Configuration:
YOCTO version => rocko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50883): https://lists.yoctoproject.org/g/yocto/message/50883
Mute This Topic: https://lists.yoctoproject.org/mt/77204074/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute 
#meta-virtualization:https://lists.yoctoproject.org/g/yocto/mutehashtag/meta-virtualization
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [yocto-builds] relocate_sdk.py is failing when installing yocto3.1.2 SDK

2020-09-29 Thread Ansurivijay Ramana
Classification: HCL Internal
Hi Randi,

I'm using poky distro.

DISTRO ?= "poky"

Using Ubuntu 16.04 LTS machine. Python version available in ubuntu machine is

/usr/bin/python3 --version
Python 3.5.2


Python version available in distro is 3.8.2

tmp/work/core2-32-poky-linux/python3/3.8.2-r0/



Thanks & Regards,
Vijay

From: Randy MacLeod 
Sent: Thursday, September 17, 2020 9:40 PM
To: Ansurivijay Ramana ; Yocto discussion list 

Subject: Re: [yocto-builds] relocate_sdk.py is failing when installing 
yocto3.1.2 SDK

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]
Hi Vijay,

I have redirected this thread to the main yocto list.
The yocto-builds list is for automated build outputs
rather than discussions.


What distro are you using?
What version of python3 is provided by that distro?
On Ubu-20.04, fyi:
$ grep python3 /.../oe-core.git/scripts/relocate_sdk.py
#!/usr/bin/env python3
$ python3 --version
Python 3.8.2

../Randy

On 2020-09-17 9:49 a.m., Ansurivijay Ramana wrote:
Classification: HCL Internal
Hi ,

I have added my layer and builded the SDK in yocto 3.1.2 but relocate_sdk.py is 
failing when installing.

Please help me in fixing this.

./poky-glibc-x86_64-core-image-sato-sdk-core2-32-qemux86-toolchain-3.1.2.sh
Poky (Yocto Project Reference Distro) SDK installer version 3.1.2
=
Enter target directory for SDK (default: /opt/poky/3.1.2): 
/home/vijay/build/test3
You are about to install the SDK to "/home/vijay/build/test3". Proceed [Y/n]? Y
Extracting 
SDK.done
Setting it up...Traceback (most recent call last):
  File "/home/vijay/build/test3/relocate_sdk.py", line 244, in 
change_dl_sysdirs(e)
  File "/home/vijay/build/test3/relocate_sdk.py", line 118, in change_dl_sysdirs
sh_offset, sh_size = struct.unpack("<24xQQ24x", sh_hdr)
struct.error: unpack requires a string argument of length 64
SDK could not be set up. Relocate script failed. Abort!

Thanks & Regards,
Vijay
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.












--

# Randy MacLeod

# Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50881): https://lists.yoctoproject.org/g/yocto/message/50881
Mute This Topic: https://lists.yoctoproject.org/mt/76912603/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image

2020-09-29 Thread Monsees, Steven C (US) via lists.yoctoproject.org
Currently not using system as our default init system (investigating why but 
this might not be an option).

Is there any other utility I might use under Yocto to get similar data as that 
produced by timedatectl ?

Thanks,
Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50880): https://lists.yoctoproject.org/g/yocto/message/50880
Mute This Topic: https://lists.yoctoproject.org/mt/77180295/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #systemd:https://lists.yoctoproject.org/g/yocto/mutehashtag/systemd
Mute #linux:https://lists.yoctoproject.org/g/yocto/mutehashtag/linux
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image

2020-09-29 Thread Monsees, Steven C (US) via lists.yoctoproject.org

Is there documentation on how to set this up ?

-Original Message-
From: yocto@lists.yoctoproject.org [mailto:yocto@lists.yoctoproject.org] On 
Behalf Of Quentin Schulz
Sent: Tuesday, September 29, 2020 11:53 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #linux #systemd Having issues building command line 
utilities: ntpq, timedatectl, and ntpstat into kernel image

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Hi Steve,

On Tue, Sep 29, 2020 at 08:45:56AM -0700, Monsees, Steven C (US) via 
lists.yoctoproject.org wrote:
> I currently have "ntpq" building and installing correctly...
> 
> Can someone tell me what it takes to get the "timedatectl" command utility 
> built into Yocto kernel image ?
> 
> I see it referenced in both :
> 
> openembedded-core/meta/recipes-core/systemd/systemd_234.bb:    
> ${bindir}/timedatectl \
> poky/meta/recipes-core/systemd/systemd_234.bb:    
> ${bindir}/timedatectl \
> 

It comes with systemd. Use it as your init system and then you'll have the 
command.

Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50879): https://lists.yoctoproject.org/g/yocto/message/50879
Mute This Topic: https://lists.yoctoproject.org/mt/77180295/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #systemd:https://lists.yoctoproject.org/g/yocto/mutehashtag/systemd
Mute #linux:https://lists.yoctoproject.org/g/yocto/mutehashtag/linux
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image

2020-09-29 Thread Quentin Schulz
Hi Steve,

On Tue, Sep 29, 2020 at 08:45:56AM -0700, Monsees, Steven C (US) via 
lists.yoctoproject.org wrote:
> I currently have "ntpq" building and installing correctly...
> 
> Can someone tell me what it takes to get the "timedatectl" command utility 
> built into Yocto kernel image ?
> 
> I see it referenced in both :
> 
> openembedded-core/meta/recipes-core/systemd/systemd_234.bb:    
> ${bindir}/timedatectl \
> poky/meta/recipes-core/systemd/systemd_234.bb:    
> ${bindir}/timedatectl \
> 

It comes with systemd. Use it as your init system and then you'll have the 
command.

Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50878): https://lists.yoctoproject.org/g/yocto/message/50878
Mute This Topic: https://lists.yoctoproject.org/mt/77180295/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #systemd:https://lists.yoctoproject.org/g/yocto/mutehashtag/systemd
Mute #linux:https://lists.yoctoproject.org/g/yocto/mutehashtag/linux
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image

2020-09-29 Thread Monsees, Steven C (US) via lists.yoctoproject.org
I currently have "ntpq" building and installing correctly...

Can someone tell me what it takes to get the "timedatectl" command utility 
built into Yocto kernel image ?

I see it referenced in both :

openembedded-core/meta/recipes-core/systemd/systemd_234.bb:    
${bindir}/timedatectl \
poky/meta/recipes-core/systemd/systemd_234.bb:    
${bindir}/timedatectl \

but have yet to figure out how to get the command built and transferred to the 
kernel image.

Thanks,
Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50877): https://lists.yoctoproject.org/g/yocto/message/50877
Mute This Topic: https://lists.yoctoproject.org/mt/77180295/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #systemd:https://lists.yoctoproject.org/g/yocto/mutehashtag/systemd
Mute #linux:https://lists.yoctoproject.org/g/yocto/mutehashtag/linux
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Yocto Project Status WW39'20

2020-09-29 Thread Stephen Jolley
Current Dev Position: YP 3.2 M4

Next Deadline: YP 3.2 M4 Feature Freeze - Now

 

Next Team Meetings:

*   Bug Triage meeting Thursday Oct. 1st at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Oct. 6th at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday Sept. 29th at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP M3 rc2 has been through QA. We have resolved the beaglebone and
bitbake UI issues, the ptest issues remain and need attention in M4. It is
likely M3 rc2 will be released.
*   YP 3.1.3 is currently going through QA.
*   Unfortunately intermittent autobuilder issues, whilst reduced, do
still remain.
*   Issues with file mode corruption in pseudo have been identified and
we're concerned this may be going undetected in the majority of cases. The
issue uncovered would explain several odd bugs we've seen over the last few
years where file mode bits have disappeared. There are some experimental
pseudo patches available that reduce the impact and frequency of these
issues but as yet we don't have a full solution. We're hampered by a lack of
a pseudo maintainer with both the availability and experience to be able to
help.
*   We continue to struggle with a number of autobuilder intermittent
bugs. You can see the list of failures we're continuing to see by searching
for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated, unfortunately it is
proving hard to find anyone interested in helping figure these out and they
significantly hamper our testing.

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 3.2. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.

 

YP 3.2 Milestone Dates:

*   YP 3.2 M3 is out of QA and should release soon.
*   YP 3.2 M4 build date 2020/10/5
*   YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

*   YP 3.1.3 is built and in QA
*   YP 3.1.4 build date 2020/11/2
*   YP 3.1.4 release date 2020/11/13

 

Tracking Metrics:

*   WDD 2481 (last week 2469) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1270 (last week 1268)
*   Patches in the Pending State: 493 (39%) [last week 496 (39%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50876): https://lists.yoctoproject.org/g/yocto/message/50876
Mute This Topic: https://lists.yoctoproject.org/mt/77197720/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-security][master][dunfell][PATCH] gitignore added

2020-09-29 Thread akuster


On 9/22/20 11:25 PM, Adrian Freihofer wrote:
> After running testimage there are some python left overs at
> lib/oeqa/runtime/cases/__pycache__/
>
> Signed-off-by: Adrian Freihofer 
merged
thanks
> ---
>  .gitignore | 7 +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 .gitignore
>
> diff --git a/.gitignore b/.gitignore
> new file mode 100644
> index 000..c01df45
> --- /dev/null
> +++ b/.gitignore
> @@ -0,0 +1,7 @@
> +*.pyc
> +*.pyo
> +/*.patch
> +*.swp
> +*.orig
> +*.rej
> +*~
>
> 
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50875): https://lists.yoctoproject.org/g/yocto/message/50875
Mute This Topic: https://lists.yoctoproject.org/mt/77029779/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [meta-security][PATCH] packagegroup-core-security: add opendnssec to pkg grp

2020-09-29 Thread akuster
Signed-off-by: Armin Kuster 
---
 recipes-core/packagegroup/packagegroup-core-security.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb 
b/recipes-core/packagegroup/packagegroup-core-security.bb
index c69e3b3..789f4ea 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -38,6 +38,7 @@ RDEPENDS_packagegroup-security-utils = "\
 python3-scapy \
 softhsm \
 libest \
+opendnssec \
 ${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 ", "", " 
libseccomp",d)} \
 ${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd 
google-authenticator-libpam", "",d)} \
 ${@bb.utils.contains("DISTRO_FEATURES", "pax", "pax-utils packctl", "",d)} 
\
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50874): https://lists.yoctoproject.org/g/yocto/message/50874
Mute This Topic: https://lists.yoctoproject.org/mt/77196749/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto] [yocto-kernel][yocto-kernel-cache] [Discussion] How about disable CONFIG_GCC_PLUGINS by default in ktypes/base/base.cfg

2020-09-29 Thread Bruce Ashfield
On Mon, Sep 28, 2020 at 10:30 PM Xu, Yanfei  wrote:
>
>
>
> On 9/9/20 12:02 PM, Bruce Ashfield wrote:
> > On Tue, Sep 8, 2020 at 8:23 AM Bruce Ashfield via
> > lists.yoctoproject.org
> >  wrote:
> >>
> >> On Tue, Sep 8, 2020 at 5:15 AM Xu, Yanfei  wrote:
> >>>
> >>>
> >>>
> >>> On 9/8/20 10:26 AM, Xu, Yanfei wrote:
> 
> 
>  On 9/8/20 10:01 AM, Bruce Ashfield wrote:
> > On Mon, Sep 7, 2020 at 11:43 AM Xu, Yanfei 
> > wrote:
> >>
> >>
> >>
> >> On 9/7/20 7:53 PM, Bruce Ashfield wrote:
> >>> On Mon, Sep 7, 2020 at 5:56 AM Xu, Yanfei 
> >>> wrote:
> 
>  Hi Bruce,
> 
> 
>  When I excuted "make -C /usr/src/kernel scripts prepare" on target
>  mechine, I will be asked for choicing if to enable "GCC_PLUGINS" and
>  other configurations depend on "GCC_PLUGINS" (The .config file didn,t
>  contain 'GCC_PLUGINS is not set')
>  But there were never be asked for these before yocto add the
>  configuration which is "EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX}
>  ${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}""
> 
> >>>
> >>> Which machine and configuration are you seeing that in ? I've modified
> >>> devsrc several times to remove the triggers that cause that behaviour,
> >>> and would like to see how it crept back in.
> >>>
> >> Firstly, the commit:'kernel.bbclass: Configuration for environment
> >> with
> >> HOSTCXX' expose this problem. After revert it, everything will be
> >> normal.
> >>
> >> Secondly, the mechine is qemuarm64. Which configuration you mean? The
> >
> > yes, which machine and image type.
> >
> >> project's configuration is normal and only with ""IMAGE_INSTALL +=
> >> "packagegroup-core-buildessential".  The configurations of Kconfig for
> >> choosing is as the blow log messages.
> >
> > I assume you are also installing kernel-devsrc on the target ?
> > Yes.
> 
> >>
>  With these, I met a failure during compiling an external module on
>  target mechine after I enabled the GCC_PLUGINS and
>  CONFIG_GCC_PLUGIN_RANDSTRUCT by above methond. Failure messages as
>  below. There might be some other unexpected situations with 
>  GCC_PLUGIN
>  enabled.
> 
>  In my oppinion, GCC_PLUGINS is rarely used, and It can be enable by
>  who
>  want to use it. So how about disable it by defualt in
>  ktypes/base/base.cfg file? Do you think it is appropriate?
> >>>
> >>> I don't disagree, but also, the configuration phase shouldn't be
> >>> triggered on target, so I'll fix that behaviour first.
> >>
> >> That's great!
> >
> > I was just able to build master, with kernel 5.8 and run the scripts
> > prepare target without triggering this:
> >
> > scripts/Makefile.build:415: warning: overriding recipe for target
> > 'modules.order'
> > Makefile:1371: warning: ignoring old recipe for target 'modules.order'
> > CC  arch/arm64/kernel/vdso/vgettimeofday.o
> > AS  arch/arm64/kernel/vdso/note.o
> > AS  arch/arm64/kernel/vdso/sigreturn.o
> > LD  arch/arm64/kernel/vdso/vdso.so.dbg
> > VDSOSYM include/generated/vdso-offsets.h
> > make: Leaving directory '/lib/modules/5.8.5-yocto-standard/build'
> > root@qemuarm64:/usr/src/kernel#
> >
> > Which is what I expected, since this is an effort I made when
> > introducing the 5.8 kernel. I'll retest with
> > 5.4 now.
>  I'm sorry for omitting an imformation about that my project added many
>  nativesdks. I will ensure if the issue was triggered by these soon.
> >>>
> >>> These nativesdks are irrelevant to the result.
> >>>
> >>> I separately build projects with kernel5.4 and kernel5.8. There are some
> >>> differences about CONFIG_GCC_PLUGINS of /usr/src/kernel/.config on
> >>> target machine.
> >>>
> >>> ---5.4-
> >>> CONFIG_PLUGIN_HOSTCC=""
> >>> CONFIG_HAVE_GCC_PLUGINS=y
> >>> # end of General architecture-dependent options
> >>>
> >>> ---5.8-
> >>> CONFIG_HAVE_GCC_PLUGINS=y
> >>> CONFIG_GCC_PLUGINS=y
> >>> # CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set
> >>> # CONFIG_GCC_PLUGIN_RANDSTRUCT is not set
> >>> # end of General architecture-dependent options
> >>
> >> Also, with the 5.4 kernel, I was able to trigger one on-target
> >> configuration run. I'll look into that first, and then get back to the
> >> gcc plugins config question.
> >
> > I have a fix for this now, and it will work for both 5.8 and 5.4 kernels.
> >
> > I need to test it a bit more, but I'll send the patch on my Wednesday
> > (since it is already Wednesday for you :)
> >
> > Bruce
> >
> Hi Bruce,
>
> With your fix, the problem is still here when I test it these day. And
> It only occur on 5.4 kernel.
>
> message as blow:
>
> 

Re: [yocto] File collision: same path from 2 recipes

2020-09-29 Thread Laurent Gauthier
Hehe, who needs a new command when you have already have "echo" :-)

On Tue, Sep 29, 2020 at 2:59 PM Quentin Schulz <
quentin.sch...@streamunlimited.com> wrote:

> On Tue, Sep 29, 2020 at 02:56:28PM +0200, Laurent Gauthier wrote:
> > I would guess so.
> >
> > Here is a way to figure out all the packages in which your file is
> > delivered (small trick that has proven quite useful for me to figure out
> > which recipe/package provides a specific file):
> >
> > 1. cd 
> > 2. echo
> tmp/work/*/*/*/packages-split/*/etc/network/if-up,d/hostapd_restart
> >
> > This will show you which packages have the file
> > "/etc/network/if-up,d/hostapd_restart".
> >
> > If you just want to check which recipe installs it (in case it is
> installed
> > by the recipe, but not packaged):
> >
> > 1. cd 
> > 2. echo tmp/work/*/*/*/package/etc/network/if-up,d/hostapd_restart
> >
>
> If available in krogoth,
> `oe-pkdata-util find-path /etc/network/if-up,d/hostapd_restart` does
> this exact thing :)
>
> Quentin
>
> > I hope this helps.
> >
> > Kind Regards, Laurent.
> >
> > PS: in some configurations of your build you might have to adjust the
> name
> > of the "tmp" directory.
> >
> >
> > On Tue, Sep 29, 2020 at 2:37 PM Mauro Ziliani 
> wrote:
> >
> > > Thanks for your help.
> > >
> > > I'm working with an old Krogoth.
> > >
> > > This checks is true even with Krogoth?
> > >
> > >
> > > MZ
> > > Il 29/09/20 14:17, Laurent Gauthier ha scritto:
> > >
> > > Hi Mauro,
> > >
> > > From my experience there should be an error reported during the image
> > > creation as long as the two *packages* that contain a file with the
> same
> > > name are BOTH installed in the root filesystem.
> > >
> > > If you don't receive an error I would suspect that for some reason the
> > > file is really only installed by one of the two packages.
> > >
> > > Another source of your issue is that there can be more than one package
> > > created by one recipe, and maybe you are not installing the package
> which
> > > contains the contentious file.
> > >
> > > Kind Regards, Laurent.
> > >
> > > On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani 
> > > wrote:
> > >
> > >> Hi all.
> > >>
> > >> There is a QA to test if 2 recipes try to install a file with the same
> > >> path?
> > >>
> > >> In my BSP 2 recipes try install the file
> > >> ${D}/etc/network/if-up,d/hostapd_restart
> > >>
> > >>
> > >> I'd like receive an error from bitbale
> > >>
> > >>
> > >> Best regards,
> > >>
> > >>
> > >> MZ
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Laurent Gauthier
> > > Embedded Linux Systems & Software
> > > Phone: +33 630 483 429
> > > http://soccasys.com
> > >
> > >
> >
> > --
> > Laurent Gauthier
> > Embedded Linux Systems & Software
> > Phone: +33 630 483 429
> > http://soccasys.com
>
> >
> > 
> >
>
>
> --
> StreamUnlimited Engineering GmbH
> High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
> Fax: +43 1 667 20 02 4401
> quentin.sch...@streamunlimited.com, www.streamunlimited.com
>


-- 
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50873): https://lists.yoctoproject.org/g/yocto/message/50873
Mute This Topic: https://lists.yoctoproject.org/mt/77194296/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] File collision: same path from 2 recipes

2020-09-29 Thread Quentin Schulz
On Tue, Sep 29, 2020 at 02:56:28PM +0200, Laurent Gauthier wrote:
> I would guess so.
> 
> Here is a way to figure out all the packages in which your file is
> delivered (small trick that has proven quite useful for me to figure out
> which recipe/package provides a specific file):
> 
> 1. cd 
> 2. echo tmp/work/*/*/*/packages-split/*/etc/network/if-up,d/hostapd_restart
> 
> This will show you which packages have the file
> "/etc/network/if-up,d/hostapd_restart".
> 
> If you just want to check which recipe installs it (in case it is installed
> by the recipe, but not packaged):
> 
> 1. cd 
> 2. echo tmp/work/*/*/*/package/etc/network/if-up,d/hostapd_restart
> 

If available in krogoth,
`oe-pkdata-util find-path /etc/network/if-up,d/hostapd_restart` does
this exact thing :)

Quentin

> I hope this helps.
> 
> Kind Regards, Laurent.
> 
> PS: in some configurations of your build you might have to adjust the name
> of the "tmp" directory.
> 
> 
> On Tue, Sep 29, 2020 at 2:37 PM Mauro Ziliani  wrote:
> 
> > Thanks for your help.
> >
> > I'm working with an old Krogoth.
> >
> > This checks is true even with Krogoth?
> >
> >
> > MZ
> > Il 29/09/20 14:17, Laurent Gauthier ha scritto:
> >
> > Hi Mauro,
> >
> > From my experience there should be an error reported during the image
> > creation as long as the two *packages* that contain a file with the same
> > name are BOTH installed in the root filesystem.
> >
> > If you don't receive an error I would suspect that for some reason the
> > file is really only installed by one of the two packages.
> >
> > Another source of your issue is that there can be more than one package
> > created by one recipe, and maybe you are not installing the package which
> > contains the contentious file.
> >
> > Kind Regards, Laurent.
> >
> > On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani 
> > wrote:
> >
> >> Hi all.
> >>
> >> There is a QA to test if 2 recipes try to install a file with the same
> >> path?
> >>
> >> In my BSP 2 recipes try install the file
> >> ${D}/etc/network/if-up,d/hostapd_restart
> >>
> >>
> >> I'd like receive an error from bitbale
> >>
> >>
> >> Best regards,
> >>
> >>
> >> MZ
> >>
> >>
> >> 
> >>
> >>
> >
> > --
> > Laurent Gauthier
> > Embedded Linux Systems & Software
> > Phone: +33 630 483 429
> > http://soccasys.com
> >
> >
> 
> -- 
> Laurent Gauthier
> Embedded Linux Systems & Software
> Phone: +33 630 483 429
> http://soccasys.com

> 
> 
> 


-- 
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.sch...@streamunlimited.com, www.streamunlimited.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50872): https://lists.yoctoproject.org/g/yocto/message/50872
Mute This Topic: https://lists.yoctoproject.org/mt/77194296/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] File collision: same path from 2 recipes

2020-09-29 Thread Laurent Gauthier
I would guess so.

Here is a way to figure out all the packages in which your file is
delivered (small trick that has proven quite useful for me to figure out
which recipe/package provides a specific file):

1. cd 
2. echo tmp/work/*/*/*/packages-split/*/etc/network/if-up,d/hostapd_restart

This will show you which packages have the file
"/etc/network/if-up,d/hostapd_restart".

If you just want to check which recipe installs it (in case it is installed
by the recipe, but not packaged):

1. cd 
2. echo tmp/work/*/*/*/package/etc/network/if-up,d/hostapd_restart

I hope this helps.

Kind Regards, Laurent.

PS: in some configurations of your build you might have to adjust the name
of the "tmp" directory.


On Tue, Sep 29, 2020 at 2:37 PM Mauro Ziliani  wrote:

> Thanks for your help.
>
> I'm working with an old Krogoth.
>
> This checks is true even with Krogoth?
>
>
> MZ
> Il 29/09/20 14:17, Laurent Gauthier ha scritto:
>
> Hi Mauro,
>
> From my experience there should be an error reported during the image
> creation as long as the two *packages* that contain a file with the same
> name are BOTH installed in the root filesystem.
>
> If you don't receive an error I would suspect that for some reason the
> file is really only installed by one of the two packages.
>
> Another source of your issue is that there can be more than one package
> created by one recipe, and maybe you are not installing the package which
> contains the contentious file.
>
> Kind Regards, Laurent.
>
> On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani 
> wrote:
>
>> Hi all.
>>
>> There is a QA to test if 2 recipes try to install a file with the same
>> path?
>>
>> In my BSP 2 recipes try install the file
>> ${D}/etc/network/if-up,d/hostapd_restart
>>
>>
>> I'd like receive an error from bitbale
>>
>>
>> Best regards,
>>
>>
>> MZ
>>
>>
>> 
>>
>>
>
> --
> Laurent Gauthier
> Embedded Linux Systems & Software
> Phone: +33 630 483 429
> http://soccasys.com
>
>

-- 
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50871): https://lists.yoctoproject.org/g/yocto/message/50871
Mute This Topic: https://lists.yoctoproject.org/mt/77194296/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] File collision: same path from 2 recipes

2020-09-29 Thread Mauro Ziliani

Thanks for your help.

I'm working with an old Krogoth.

This checks is true even with Krogoth?


MZ

Il 29/09/20 14:17, Laurent Gauthier ha scritto:

Hi Mauro,

From my experience there should be an error reported during the image 
creation as long as the two *packages* that contain a file with the 
same name are BOTH installed in the root filesystem.


If you don't receive an error I would suspect that for some reason the 
file is really only installed by one of the two packages.


Another source of your issue is that there can be more than one 
package created by one recipe, and maybe you are not installing the 
package which contains the contentious file.


Kind Regards, Laurent.

On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani > wrote:


Hi all.

There is a QA to test if 2 recipes try to install a file with the
same path?

In my BSP 2 recipes try install the file
${D}/etc/network/if-up,d/hostapd_restart


I'd like receive an error from bitbale


Best regards,


    MZ







--
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50870): https://lists.yoctoproject.org/g/yocto/message/50870
Mute This Topic: https://lists.yoctoproject.org/mt/77194296/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] File collision: same path from 2 recipes

2020-09-29 Thread Robert P. J. Day


Quoting Laurent Gauthier :


Hi Mauro,

From my experience there should be an error reported during the image
creation as long as the two *packages* that contain a file with the same
name are BOTH installed in the root filesystem.

If you don't receive an error I would suspect that for some reason the file
is really only installed by one of the two packages.

Another source of your issue is that there can be more than one package
created by one recipe, and maybe you are not installing the package which
contains the contentious file.

Kind Regards, Laurent.

On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani  wrote:


Hi all.

There is a QA to test if 2 recipes try to install a file with the same
path?

In my BSP 2 recipes try install the file
${D}/etc/network/if-up,d/hostapd_restart


I'd like receive an error from bitbale


  I was just about to weigh in on this as I was just educated by
Richard Purdie as to the (im)proper use of SSTATE_DUPWHITELIST.
If two packages were truly trying to install the same file, I would
have assumed that you would have received an error to that effect,
so the fact that you aren't suggests one of:

 * they're not really trying to install the same file
 * you're installing only one of the packages
 * perhaps there is a do_install_append() that is manually
   removing the conflicting file from one of the recipes

  My opinion, FWIW.

rday


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50869): https://lists.yoctoproject.org/g/yocto/message/50869
Mute This Topic: https://lists.yoctoproject.org/mt/77194296/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] File collision: same path from 2 recipes

2020-09-29 Thread Laurent Gauthier
Hi Mauro,

>From my experience there should be an error reported during the image
creation as long as the two *packages* that contain a file with the same
name are BOTH installed in the root filesystem.

If you don't receive an error I would suspect that for some reason the file
is really only installed by one of the two packages.

Another source of your issue is that there can be more than one package
created by one recipe, and maybe you are not installing the package which
contains the contentious file.

Kind Regards, Laurent.

On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani  wrote:

> Hi all.
>
> There is a QA to test if 2 recipes try to install a file with the same
> path?
>
> In my BSP 2 recipes try install the file
> ${D}/etc/network/if-up,d/hostapd_restart
>
>
> I'd like receive an error from bitbale
>
>
> Best regards,
>
>
> MZ
>
>
> 
>
>

-- 
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50868): https://lists.yoctoproject.org/g/yocto/message/50868
Mute This Topic: https://lists.yoctoproject.org/mt/77194296/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] File collision: same path from 2 recipes

2020-09-29 Thread Mauro Ziliani

Hi all.

There is a QA to test if 2 recipes try to install a file with the same path?

In my BSP 2 recipes try install the file 
${D}/etc/network/if-up,d/hostapd_restart



I'd like receive an error from bitbale


Best regards,


   MZ


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50867): https://lists.yoctoproject.org/g/yocto/message/50867
Mute This Topic: https://lists.yoctoproject.org/mt/77194296/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto] Interim task between compile/bundle_initramfs

2020-09-29 Thread Bruce Ashfield
On Mon, Sep 28, 2020 at 6:45 PM Sean McKay  wrote:
>
> Hi Bruce, et al.
>
> Has anyone given any thought to trying to add an sstate enabled task between 
> compile and bundle_initramfs that would capture the necessary artifacts for 
> the downstream tasks to run without necessarily actually recompiling the 
> kernel if nothing in the kernel code/config has changed?
> I ask because we’ve got a few embedded systems that use just a bundled 
> kernel/initramfs to run, and it seems quite a waste of compute time to 
> recompile the kernel every time the initramfs changes image signature (and we 
> can’t be the only ones for whom the compute time savings would be nonzero).
>
>
> On the other hand, I’m guessing smarter people than I have already thought of 
> said question… so before I dig too far, I figured I’d ask if there’s a reason 
> this hasn’t been done, or if you think it’s worth pursuing (and no one else 
> has had the time yet)?

It has been thought about, but I've never seen a complete enough
solution to it to consider for merging.

That being said, some of the core features that have added/fixed to
bitbake/oe in the last year or so, should help with this (everything
from sstate fixes to hash equiv to multiconfig).

Fundamentally you are talking about a task to re-pack the initramfs
based on (sstate) artifacts. This is something that could have been
forced/done in a custom class based on deployed artifacts only, but
using sstate would catch cases where things did change, and you really
shouldn't be using the deployed variants.

I think it is worth pursuing, but I'm sure there are corner cases I'm
not catching off the top of my head.

I'd be interested in helping with any POCs or design elements (or
implementation), etc. So feel free to fire things off to me or the
list as you need.

Bruce

>
> Thanks!
>
> -Sean McKay
>
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9097): 
https://lists.yoctoproject.org/g/linux-yocto/message/9097
Mute This Topic: https://lists.yoctoproject.org/mt/77185489/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-