Re: [yocto] Switching between multiple DISTROs without "contamination"
Thanks Martin and Mike for your explanations and tips.
So, I've done a lot of testing today and it seems I simplified the
example in my first email a bit too much. The example as-is works fine
when switching DISTROs as far as I can tell. The problem only arises
when wildcards are used.
Changing my initial example like this should trigger the behaviour I've
initially described:
SRC_URI:append:mydistro-dev = " file://application-dbg.service"
do_install {
# ...snip...
# systemd service
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/*.service ${D}${systemd_system_unitdir}
}
do_install:append:mydistro-dev() {
# debug systemd services
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/application-dbg.service
${D}${systemd_system_unitdir}
}
Notice the *.service in do_install.
>From my testing, this is how contamination happens:
1) Build with 'DISTRO=mydistro bitbake application'. All tasks for the
recipe are run and the directories in WORKDIR are populated, including
the "application.service" file.
2) Build with 'DISTRO=mydistro-dev bitbake application'. do_unpack is
rerun and places the additional "application-dbg.service" file in
WORKDIR.
3) Switching back to 'mydistro' will get the recipe from sstate cache,
which works fine.
4) Changing application.bb and rebuilding with 'DISTRO=mydistro bitbake
application' reruns do_install (as expected). This leads to the
packages do_install picking up the additional "application-dbg.service"
file left behind by the invocation in step 2).
Mike, Martin: Do you remember in which cases you encountered problems
when sharing the build directory?
On Tue, 2022-07-12 at 09:15 -0700, Khoi Dinh Trinh wrote:
> Thank you Nicolas for asking this question since I will probably run
> into this issue soon if not for this email thread. The answers so far
> have been very helpful but I just want to clarify a bit more on why
> doesn't the package get rebuilt? From my understanding, Yocto should
> rerun a task when the signature of the task changes and since
> do_install has an override on mydistro-dev, shouldn't the content and
> thus the signature of do_install change when switching distro and so
> Yocto should rerun it?
As far as I can tell, all the relevant tasks are rerun correctly when
something is changed. Relevant tasks meaning only the tasks that are
actually different.
The specific issue I experienced is due to the WORKDIR not being
cleaned between different task invocations and the recipe (probably
wrongfully) relying on wildcards to gather files, see example above.
> I have a lot of tasks with override not just on DISTRO but other
> things like MACHINE or custom variables so I want to understand the
> rebuild mechanism as best I can.
>
There's surely someone more knowledgeable here that could clarify the
inner workings of this mechanism a lot better than me.
> Best,
> Khoi Trinh
>
> On Tue, Jul 12, 2022 at 8:05 AM Mike Looijmans
> wrote:
> > Quick answer: Don't build multiple distros in one build directory.
> >
It's really a bummer that it's not reliably possible to switch between
DISTROs inside one build directory.
> > You might get away with setting TMPDIR = "tmp-${DISTRO}" to give
> > each
> > its own.
> >
> > But I'd rather advice to set up two separate builds and just point
> > the
> > downloads and sstate-cache to the same location. It'll be faster
> > than
> > the TMPDIR option.
> >
> > Or figure out how to put the difference in the IMAGE only. Then you
> > can
> > just build both images (in parallel, woot), which is faster, more
> > convenient and saves on diskspace.
As I'm currently working with something close to what you describe, I
think I'll try to stay away from multiple DISTROs if possible and
improve on what I'm already doing.
> >
> > What I often do is have my-application.bb generate a
> > my-application-utils package that only gets installed in the "dev"
> > image
> > but not in the production one, which only installs "my-
> > application".
This is probably what Martin meant with his A.bb and A-xx.bb example.
It's so far one of the best approaches I've seen, thanks.
> >
> > You could also create a "my-application-dev.bb" recipe that
> > includes
> > my-application.bb and just changes what it needs to be different.
> >
> >
> >
> >
> > Met vriendelijke groet / kind regards,
> >
> > Mike Looijmans
> > System Expert
> >
> >
> > TOPIC Embedded Products B.V.
> > Materiaalweg 4, 568
Re: [yocto] How to get license text
On Mon, 2022-07-11 at 10:00 -0700, William Huang wrote:
> Hi,
> I was wondering if it is possible to get the license information for
> all of the deployed packages in the image? I know there's a
> license.manifest file in deploy/licenses, but I'm looking for a file
> that includes that manifest as well as the paragraph associated with
> the license. Closest I found was in the /usr/share/common-license
> folder which has the LICENSE or COPYING file for each package, but I
> am looking if there's a single file that contains this information
> instead.
>
I started working on something like this as I'm currently not aware
that this functionality already exists (someone correct me if I'm
wrong). My goal was to create a PDF with a list of packets and all
licenses. The design I chose was creating something text based directly
out of yocto (markdown) and using something like pandoc to convert that
to a PDF. I've abandoned the project for the moment as other things
became more important.
This is what I have so far, it currently depends on python tabulate and
generally has some rough edges. I called it "credits.bbclass" and just
used "inherit credits" in my image task. If someone wants to continue
working on it, go for it.
CREDITS_DIR ??= "${DEPLOY_DIR}"
CREDITS_FILENAME ??= "credits.md"
python create_credit_file() {
# bb.plain("Connect debugger now")
# import epdb; epdb.serve()
import re
import oe.packagedata
from oe.rootfs import image_list_installed_packages
build_images_from_feeds = d.getVar('BUILD_IMAGES_FROM_FEEDS')
if build_images_from_feeds == "1":
return 0
# list of packages and their corresponding licenses
license_summary = []
# list of generic licenses
generic_licenses = []
# dictionary of packages and their license files
license_details = {}
# set of licenses to exclude
exclude = set(d.getVar(('CREDITS_EXCLUDE_LICENSES') or "").split())
for pkg in sorted(image_list_installed_packages(d)):
# obtain and process basic information about the package
pkg_info_path = os.path.join(d.getVar('PKGDATA_DIR'),
'runtime-reverse', pkg)
pkg_name = os.path.basename(os.readlink(pkg_info_path))
pkg_data = oe.packagedata.read_pkgdatafile(pkg_info_path)
if not "LICENSE" in pkg_data.keys():
pkg_lic_name = "LICENSE_" + pkg_name
pkg_data["LICENSE"] = pkg_data[pkg_lic_name]
pkg_license_list = re.sub(r'[|&()*]', ' ', pkg_data["LICENSE"])
pkg_license_list = re.sub(r' *', ' ',
pkg_license_list).split()
# skip package if one of it's licenses is in the exclude set
if set(pkg_license_list).intersection(exclude):
continue
# create summary entry
license_summary.append(( pkg_name, pkg_data["LICENSE"] ))
# create generic and detail entries
pkg_license_dir = os.path.join(d.getVar('LICENSE_DIRECTORY'),
pkg_data["PN"])
pkg_manifest_licenses = [canonical_license(d, lic) \
for lic in pkg_license_list]
licenses = os.listdir(pkg_license_dir)
for lic in licenses:
if re.match(r"^generic_.*$", lic):
generic_lic = canonical_license(d,
re.search(r"^generic_(.*)$", lic).group(1))
# ignore generic licenses that are not declared in
LICENSES
if not re.sub(r'\+$', '', generic_lic) in \
[re.sub(r'\+', '', lic) for lic in \
pkg_manifest_licenses]:
continue
if generic_lic not in generic_licenses:
generic_licenses.append(generic_lic)
else:
license_details.setdefault(pkg, []) \
.append(os.path.join(pkg_license_dir, lic))
credit_file_dir = os.path.join(d.getVar('CREDITS_DIR'))
bb.utils.mkdirhier(credit_file_dir)
credit_file_path = os.path.join(credit_file_dir,
d.getVar('CREDITS_FILENAME'))
write_credit_file(d, credit_file_path, license_summary,
generic_licenses)
}
def write_credit_file(d, path, license_summary, generic_licenses):
from tabulate import tabulate
with open(path, "w") as credit_file:
credit_file.write("# Summary\n\n")
credit_file.write(tabulate(license_summary,
headers=["Package", "License"],
tablefmt="github"))
credit_file.write("\n\n")
credit_file.write("# Generic Licenses\n\n")
generic_directory = d.getVar('COMMON_LICENSE_DIR')
for generic_license in generic_licenses:
credit_file.write(f"## {generic_license}\n\n")
generic_file_path = os.path.join(generic_directory,
generic_license)
if os.path.isfile(generic_file_path):
credit_fil
[yocto] Switching between multiple DISTROs without "contamination"
Hi all,
I'm currently using an additional layer and image to differentiate
between a release and development build (enabling NFS, SSH, root login,
etc.). To create a development build, I manually add the layer to
bblayers.conf. This works quite well, but feels a bit clumsy to
integrate into a CI/CD pipeline.
Per these past discussions here [1][2], I'm now trying to migrate to
multiple DISTROs, something like "mydistro" and "mydistro-dev".
While migrating some of the changes, I discovered that I run into
caching(?) issues. I have a recipe for an internal application and want
to include additional systemd service files in the development image.
What I did was this:
Added "application-dbg.service" to recipes-internal/application/files
Adapted application.bb recipe:
SRC_URI:append:mydistro-dev = " file://application-dbg.service"
do_install {
# ...snip...
# systemd service
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/application.service
${D}${systemd_system_unitdir}
}
do_install:append:mydistro-dev() {
# debug systemd services
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/application-dbg.service
${D}${systemd_system_unitdir}
}
When I run "DISTRO=mydistro-dev bitbake application" followed by
"DISTRO=mydistro bitbake application", the debug service file is still
present in the package. This seems to be caused by the "image"
directory in the recipe WORKDIR not being cleaned between subsequent
do_install runs. Is this expected behaviour? What's the best solution?
Kind regards,
Nicolas
[1]:
https://lore.kernel.org/yocto/CAH9dsRiArf_9GgQS4hCg5=j_jk6cd3eigaoiqd788+isltu...@mail.gmail.com/
[2]:
https://lore.kernel.org/yocto/vi1pr0602mb3549f83ac93a53785de48677d3...@vi1pr0602mb3549.eurprd06.prod.outlook.com/
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57508): https://lists.yoctoproject.org/g/yocto/message/57508
Mute This Topic: https://lists.yoctoproject.org/mt/92332946/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Yocto cyrillic characters support #yocto
On Fri, 2022-04-29 at 06:48 -0700, Ashutosh Naik wrote: > I am having trouble creating files with cyrillic characters on a > yocto generated image. > > For eg. If I try to create a file like : > # touch 1Черная > > I do get: > > # ls > 1?? Is your file created with the wrong name or is it actually just the 'ls' output that doesn't support unicode characters? If you're using busybox, I think these configuration options could be of interest: CONFIG_UNICODE_SUPPORT CONFIG_LAST_SUPPORTED_WCHAR You'll find this at the bottom of "Settings -> Support Unicode" when using menuconfig. > I have verified that my locale has utf8 support: > > # locale > LANG=en_GB.utf8 > LC_CTYPE="en_GB.utf8" > LC_NUMERIC="en_GB.utf8" > LC_TIME="en_GB.utf8" > LC_COLLATE="en_GB.utf8" > LC_MONETARY="en_GB.utf8" > LC_MESSAGES="en_GB.utf8" > LC_PAPER="en_GB.utf8" > LC_NAME="en_GB.utf8" > LC_ADDRESS="en_GB.utf8" > LC_TELEPHONE="en_GB.utf8" > LC_MEASUREMENT="en_GB.utf8" > LC_IDENTIFICATION="en_GB.utf8" > LC_ALL=en_GB.utf8 > > What could I be missing and how can I create files with cyrillic > characters? > > Regards > Ash -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56973): https://lists.yoctoproject.org/g/yocto/message/56973 Mute This Topic: https://lists.yoctoproject.org/mt/90776055/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] firewalld isssue #yocto
On Sun, 2022-03-27 at 23:39 -0700, sateesh m wrote:
> Hi Team,
>
> I have built a custom image core-image-base on riscv
> target machine installed nftables,firewalld,JSON packages support. I
> am using firewalld_0.9.3 sources depends nftables-python is present.
> But I am getting error python-nftables. Can you please guide me on
> what dependent I missed here? If suppose firewalld should work means,
> What packages should I install?
>
> But while running firewalld status is always failed mode.
> Using $firewall-cmd --reload I am facing a problem
>
> Error: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0:
> Error: Could not process rule: No such file or directory
>
Judging by this stack exchange thread[1] from a quick search, you might
be missing the appropriate kernel configs[2].
[1]: https://unix.stackexchange.com/questions/632113
[2]: https://wiki.gentoo.org/wiki/Nftables#Kernel
>
> JSON blob:
> {"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add":
> {"chain": {"family": "inet", "table": "firewalld", "name":
> "raw_PREROUTING", "type": "filter", "hook": "prerouting", "prio": -
> 290}}}, {"add": {"chain": {"family": "inet", "table": "firewalld",
> "name": "mangle_PREROUTING", "type": "filter", "hook": "prerouting",
> "prio": -140}}}, {"add": {"chain": {"family": "inet", "table":
> "firewalld", "name": "mangle_PREROUTING_POLICIES_pre"}}}, {"add":
> {"rule": {"family": "inet", "table": "firewalld", "chain":
> "mangle_PREROUTING", "expr": [{"jump": {"target":
> "mangle_PREROUTING_POLICIES_pre"}}]}}}, {"add": {"chain": {"family":
> "inet", "table": "firewalld", "name": "mangle_PREROUTING_ZONES"}}},
> {"add": {"rule": {"family": "inet", "table": "firewalld", "chain":
> "mangle_PREROUTING", "expr": [{"jump": {"target":
> "mangle_PREROUTING_ZONES"}}]}}}, {"add": {"chain": {"family": "inet",
> "table": "firewalld", "name": "mangle_PREROUTING_POLICIES_post"}}},
> {"add": {"rule": {"family": "inet", "table": "firewalld", "chain":
> "mangle_PREROUTING", "expr": [{"jump": {"target":
> "mangle_PREROUTING_POLICIES_post"}}]}}}, {"add": {"chain": {"family":
> "ip", "table": "firewalld", "name": "nat_PREROUTING", "type": "nat",
> "hook": "prerouting", "prio": -90}}}, {"add": {"chain": {"family":
> "ip", "table": "firewalld", "name": "nat_PREROUTING_POLICIES_pre"}}},
> {"add": {"rule": {"family": "ip", "table": "firewalld", "chain":
> "nat_PREROUTING", "expr": [{"jump": {"target":
> "nat_PREROUTING_POLICIES_pre"}}]}}}, {"add": {"chain": {"family":
> "ip", "table": "firewalld", "name": "nat_PREROUTING_ZONES"}}},
> {"add": {"rule": {"family": "ip", "table": "firewalld", "chain":
> "nat_PREROUTING", "expr": [{"jump": {"target":
> "nat_PREROUTING_ZONES"}}]}}}, {"add": {"chain": {"family": "ip",
> "table": "firewalld", "name": "nat_PREROUTING_POLICIES_post"}}},
> {"add": {"rule": {"family": "ip", "table": "firewalld", "chain":
> "nat_PREROUTING", "expr": [{"jump": {"target":
> "nat_PREROUTING_POLICIES_post"}}]}}}, {"add": {"chain": {"family":
> "ip", "table": "firewalld", "name": "nat_POSTROUTING", "type": "nat",
> "hook": "postrouting", "prio": 110}}}, {"add": {"chain": {"family":
> "ip", "table": "firewalld", "name":
> "nat_POSTROUTING_POLICIES_pre"}}}, {"add": {"rule": {"family": "ip",
> "table": "firewalld", "chain": "nat_POSTROUTING", "expr": [{"jump":
> {"target": "nat_POSTROUTING_POLICIES_pre"}}]}}}, {"add": {"chain":
> {"family": "ip", "table": "firewalld", "name":
> "nat_POSTROUTING_ZONES"}}}, {"add": {"rule": {"family": "ip",
> "table": "firewalld", "chain": "nat_POSTROUTING", "expr": [{"jump":
> {"target": "nat_POSTROUTING_ZONES"}}]}}}, {"add": {"chain":
> {"family": "ip", "table": "firewalld", "name":
> "nat_POSTROUTING_POLICIES_post"}}}, {"add": {"rule": {"family": "ip",
> "table": "firewalld", "chain": "nat_POSTROUTING", "expr": [{"jump":
> {"target": "nat_POSTROUTING_POLICIES_post"}}]}}}, {"add": {"chain":
> {"family": "ip6", "table": "firewalld", "name": "nat_PREROUTING",
> "type": "nat", "hook": "prerouting", "prio": -90}}}, {"add":
> {"chain": {"family": "ip6", "table": "firewalld", "name":
> "nat_PREROUTING_POLICIES_pre"}}}, {"add": {"rule": {"family": "ip6",
> "table": "firewalld", "chain": "nat_PREROUTING", "expr": [{"jump":
> {"target": "nat_PREROUTING_POLICIES_pre"}}]}}}, {"add": {"chain":
> {"family": "ip6", "table": "firewalld", "name":
> "nat_PREROUTING_ZONES"}}}, {"add": {"rule": {"family": "ip6",
> "table": "firewalld", "chain": "nat_PREROUTING", "expr": [{"jump":
> {"target": "nat_PREROUTING_ZONES"}}]}}}, {"add": {"chain": {"family":
> "ip6", "table": "firewalld", "name":
> "nat_PREROUTING_POLICIES_post"}}}, {"add": {"rule": {"family": "ip6",
> "table": "firewalld", "chain": "nat_PREROUTING", "expr": [{"jump":
> {"target": "nat_PREROUTING_POLICIES_post"}}]}}}, {"add": {"chain":
> {"family": "ip6", "table": "firewalld", "name": "nat_POSTROUTING",
> "type": "nat", "hook": "postrouting", "prio": 110}}}, {"add":
> {"chain": {"family": "ip6", "table": "
Re: [yocto] CVE patch updates
On Thu, 2022-03-24 at 18:56 +, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:
>
> So, my only change to my build is the INHERIT =+ “cve-check”…
> No issue seen until this line added…
>
> Can someone tell me why when I build from scratch, clean, I see the
> following error ?
> Who’s certificate failure is being flagged ?
>
> Initialising tasks: 100%
> |
> ###| Time: 0:00:04
> Checking sstate mirror object availability: 100%
> |###|
> Time: 0:00:00
> Sstate summary: Wanted 2258 Found 2229 Missed 29 Current 0 (98%
> match, 0% complete)
> NOTE: Executing Tasks
> NOTE: Setscene tasks completed
> ERROR: cve-update-db-native-1.0-r0 do_populate_cve_db: 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:do_populate_cve_db(d)
> 0003:
> File: '/disk0/scratch/smonsees/yocto/workspace_1/poky/meta/recipes-
> core/meta/cve-update-db-native.bb', lineno: 69, function:
> do_populate_cve_db
> 0065: meta_url = year_url + ".meta"
> 0066: json_url = year_url + ".json.gz"
> 0067:
> 0068: # Retrieve meta last modified date
> *** 0069: response = urllib.request.urlopen(meta_url)
> 0070: if response:
> 0071: for l in
If you look at the source for cve-update-db-native.bb[1], you see how
the URLs are being generated. It tries to send requests to the
following URLs (if you didn't change NVDCVE_URL):
https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-{YEAR}.meta
https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-{YEAR}.json.gz
Where {YEAR} is every year from 2002 up until the current year + 1. I
suspect you might be behind a corporate firewall which does deep
inspection and replaces the certificates, but that's just a guess.
[1]:
https://git.yoctoproject.org/poky/tree/meta/recipes-core/meta/cve-update-db-native.bb
> response.read().decode("utf-8").splitlines():
> 0072: key, value = l.split(":", 1)
> 0073: if key == "lastModifiedDate":
> File: '/usr/lib64/python3.6/urllib/request.py', lineno: 223,
> function: urlopen
> 0219: elif _opener is None:
> 0220: _opener = opener = build_opener()
> 0221: else:
> 0222: opener = _opener
> *** 0223: return opener.open(url, data, timeout)
> 0224:
> 0225:def install_opener(opener):
> 0226: global _opener
> 0227: _opener = opener
> File: '/usr/lib64/python3.6/urllib/request.py', lineno: 526,
> function: open
> 0522: for processor in self.process_request.get(protocol,
> []):
> 0523: meth = getattr(processor, meth_name)
> 0524: req = meth(req)
> 0525:
> *** 0526: response = self._open(req, data)
> 0527:
> 0528: # post-process response
> 0529: meth_name = protocol+"_response"
> 0530: for processor in
> self.process_response.get(protocol, []):
> File: '/usr/lib64/python3.6/urllib/request.py', lineno: 544,
> function: _open
> 0540: return result
> 0541:
> 0542: protocol = req.type
> 0543: result = self._call_chain(self.handle_open,
> protocol, protocol +
> *** 0544: '_open', req)
> 0545: if result:
> 0546: return result
> 0547:
> 0548: return self._call_chain(self.handle_open,
> 'unknown',
> File: '/usr/lib64/python3.6/urllib/request.py', lineno: 504,
> function: _call_chain
> 0500: # could. Otherwise, they return the response.
> 0501: handlers = chain.get(kind, ())
> 0502: for handler in handlers:
> 0503: func = getattr(handler, meth_name)
> *** 0504: result = func(*args)
> 0505: if result is not None:
> 0506: return result
> 0507:
> 0508: def open(self, fullurl, data=None,
> timeout=socket._GLOBAL_DEFAULT_TIMEOUT):
> File: '/usr/lib64/python3.6/urllib/request.py', lineno: 1392,
> function: https_open
> 1388: self._check_hostname = check_hostname
> 1389:
> 1390: def https_open(self, req):
> 1391: return
> self.do_open(http.client.HTTPSConnection, req,
> *** 1392: context=self._context,
> check_hostname=self._check_hostname)
> 1393:
> 1394: https_request = AbstractHTTPHandler.do_request_
> 1395:
> 1396: __all__.append('HTTPSHandler')
> File: '/usr/lib64/python3.6/urllib/request.py', lineno: 1351,
> function: do_open
> 1347: try:
> 1348: h.request(req.get_method(), req.selector,
> req.data, headers,
>
Re: Private: Re: [yocto] Fetch private gitlab repo using ssh with Yocto recipe #bitbake
Re-adding the list. On Wed, 2022-02-02 at 11:51 -0800, Sourabh Hegde wrote: > Hi @Nicolas, Hi Sourabh > Thanks for the detailed answer. > > I followed your steps to fix ssh "config" file and now it's working > fine. Glad to hear it works now. > Regarding my build environment: I am using Docker Desktop for Windows > so i am starting container from Docker Desktop GUI, not from Windows > powershell. So I was confused how to pass "-v > $SSH_AUTH_SOCK:/ssh.socket \". I hope it's making sense here. Please > do let me know if I am doing anything wrong here so that I don't face > similar issues in future. I see, I never used Docker Desktop for Windows, so I can't give you advice about that specifically. If the ssh connection works correctly with the configuration you created, you shouldn't need to forward the ssh agent. > Thanks in advance. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56054): https://lists.yoctoproject.org/g/yocto/message/56054 Mute This Topic: https://lists.yoctoproject.org/mt/88879520/21656 Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Fetch private gitlab repo using ssh with Yocto recipe #bitbake
On Mon, 2022-01-31 at 02:54 -0800, Sourabh Hegde wrote: > Hello @Nicolas @Erik @Khem, Hi! > Update from my side: > > After following some discussion from other posts, I added "config" > file. > I think you're starting to mix various things together, you should maybe try to not do everything at the same time. I added comments about what is wrong with your config, but depending on your build environment, the ssh config is maybe not the best choice. > ~/.ssh/config: > > Host git.example.com > HostName git.example.com > User git > PreferredAuthentications publickey > IdentityFile ~/.ssh/id_ed25519.pub > # LogLevel DEBUG3 > You need to specify the private key with IdentityFile, not the public key. > Then I did "eval `ssh-agent -s`" > > Then doing "ssh-add ~/.ssh/id_ed25519.pub" results in: Same here, you should be doing "ssh-add ~/.ssh/id_ed25519" (without the .pub). > @@@ > @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ > @@@ > Permissions 0644 for '/root/.ssh/id_ed25519.pub' are too open. > It is required that your private key files are NOT accessible by > others. > This private key will be ignored. > > Whereas the permissions are set as: > > ls -l -a ~/.ssh > > -rw-r--r-- 1 root root 157 Jan 31 10:48 config > -rw--- 1 root root 464 Jan 20 15:26 id_ed25519 > -rw-r--r-- 1 root root 109 Jan 20 15:26 id_ed25519.pub > -rw-r--r-- 1 root root 888 Jan 26 08:43 known_hosts > Well, the permissions on id_ed25519 are correct, but you added the public key as private key in your config / in your ssh-add command, which doesn't have the required permissions for private keys (because it's not). > "ssh-agent" is running > > ssh-agent > SSH_AUTH_SOCK=/tmp/ssh-lcft54A4nriC/agent.2833; export SSH_AUTH_SOCK; > SSH_AGENT_PID=2834; export SSH_AGENT_PID; > echo Agent pid 2834; > > After doing these changes, when I try to "ssh -v git.example.com" to > test the connection before running bitbake, I get > > OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f 31 Mar 2020 > debug1: Reading configuration data /root/.ssh/config > debug1: /root/.ssh/config line 1: Applying options for > git.example.com > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 19: include > /etc/ssh/ssh_config.d/*.conf matched no files > debug1: /etc/ssh/ssh_config line 21: Applying options for * > debug1: Connecting to git.example.com [116.203.241.xxx] port 22. > debug1: connect to address 116.203.241.xxx port 22: Connection > refused > ssh: connect to host git.example.com port 22: Connection refused > > I don't understand what is the issue here. > > @Nicolas Can you please let me know where and how to run below > commands? Do I need to run them every time before fetching from > gitlab? > -v $SSH_AUTH_SOCK:/ssh.socket \ > -e SSH_AUTH_SOCK=/ssh.socket \ > I think you should explain your build environment a bit better, as I can just guess what you're doing. You should add these parameters when starting your docker container. For example I use something along these lines: docker run -ti --rm -v ~/development/oe-build:/workdir -v $SSH_AUTH_SOCK:$SSH_AUTH_SOCK -e SSH_AUTH_SOCK="$SSH_AUTH_SOCK" crops/poky --workdir=/workdir If you're forwarding the ssh agent like this, you don't need a key or config file at all, only known_hosts. On the other hand, if you're using e.g. GitLab pipelines with docker, you should not do it like mentioned above, but follow their guide [1]. [1]: https://docs.gitlab.com/ee/ci/ssh_keys/index.html#ssh-keys-when-using-the-docker-executor > And also I already have "known_hosts" file with matching entries for > key/agent pair. > > Can you please let me know how to make this working? > > Your help will be much appreciated. > > Thanks in advance. > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56043): https://lists.yoctoproject.org/g/yocto/message/56043 Mute This Topic: https://lists.yoctoproject.org/mt/88691891/21656 Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Fetch private gitlab repo using ssh with Yocto recipe #bitbake
On Fri, 2022-01-28 at 10:27 +, VIVAVIS AG wrote: > Hi, > > > Von: yocto@lists.yoctoproject.org Im > > Auftrag von Sourabh Hegde > > Gesendet: Freitag, 28. Januar 2022 10:47 > > > > Can you please let me know how to "forward SSH_AGENT into it to be > > able > > to fetch from internal projects without the need to mount the key > > into the container."? I never did that before. > > I use the following options within the Docker run command: > -v $SSH_AUTH_SOCK:/ssh.socket \ > -e SSH_AUTH_SOCK=/ssh.socket \ > That's pretty much what I use. > Furthermore, I had to mount the .ssh folder into the container to > make it working (be aware of security risk). > Additionally, you should check that uid, gid of the user in the > container is the same on the host. I do something similar, my "problem" was that ssh needs the .ssh/known_hosts file with a matching entry in addition to your key/agent, but mounting the .ssh folder was not possible for me because of permissions. Currently, I just created a little script that wraps "oe-init-build-env" and populates the known_hosts file accordingly. mkdir -p ~/.ssh cat <> ~/.ssh/known_hosts git.example.com ssh-ed25519 EOF > Regards, > > Carsten > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56009): https://lists.yoctoproject.org/g/yocto/message/56009 Mute This Topic: https://lists.yoctoproject.org/mt/88691891/21656 Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Fetch private gitlab repo using ssh with Yocto recipe #bitbake
On Tue, 2022-01-25 at 23:16 -0800, hrsourabh...@gmail.com wrote: > I am trying to fetch a private gitlab repo within Yocto image recipe > using SSH protocol. In my image recipe I have passed SRC_URI as: > > SRC_URI = " \ > gitsm://g...@git.example.com:2224/blah/blah/blah/blah;protocol > =ssh;branch=master \ > " I use almost the same, just without submodules. SRC_URI = "git://g...@git.example.com:1234/group/project.git;protocol=ssh" It should "just work" if ssh is able to find your key. I often build in a docker container, so I have to forward SSH_AGENT into it to be able to fetch from internal projects without the need to mount the key into the container. I don't really have any insight for builds outside docker, if git clone works, the bitbake fetcher should too. > But this results in the error: > > > But I am able to clone the repo using git clone. > SSH key is already added to the Gitlab. There is no config file in my > ~/.ssh. Do I need to create a config file? What should be the content > of the config file? You should not need a ssh config file. > Can anyone please let me know how to resolve this? > Thanks in advance. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56006): https://lists.yoctoproject.org/g/yocto/message/56006 Mute This Topic: https://lists.yoctoproject.org/mt/88691891/21656 Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Building uImage with appended DTB
> On 17 Jan 2022, at 06:41, rgovos...@gmail.com wrote: > > I'm a complete newcomer to Yocto, trying to translate a manual process of > building software for an embedded device based on the PHYTEC phyCORE-LPC3250 > SOM. I did not find an existing BSP layer for this board so I am trying to > create my own. Just a short hint if you didn’t discover it yourself, there is a (very) old BSP available from PHYTEC [1]. The downloads don’t seem to work, but they’re available on a probably forgotten FTP server [2]. [1]: https://web.archive.org/web/20120501212117/http://www.phytec.com/products/linux/bsp-LPC3180.html [2]: ftp://ftp.phytec.com/temp/PCM-031_phyCORE-LPC3180 > > When I build a kernel for this device manually, I use the > CONFIG_APPENDED_DTB=y option, which instructs the kernel to find the device > tree right after the kernel image itself. I build the zImage, then append my > DTB and finally create the uImage file: > > cat arch/arm/boot/zImage ./arch/arm/boot/dts/lpc3250-phy3250.dtb > > arch/arm/boot/zImage-dtb > mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n > Linux -d arch/arm/boot/zImage-dtb arch/arm/boot/uImage-dtb > > I'm trying to figure out how to properly replicate this process in Yocto. > > I see that Poky's meta/classes/kernel-devicetree.bbclass uses the > KERNEL_DEVICETREE_BUNDLE variable to do something similar. If I have > KERNEL_IMAGETYPE set to "zImage", then it will create a zImage+DTB file. > > However, it expects the zImage file to be called "zImage", and the one that > gets built is called "zImage-5.14.6-yocto-standard". Since it cannot find > "zImage", the build fails. > > cat: > .../tmp/work/lpc3250-poky-linux-gnueabi/linux-yocto/5.14.6+gitAUTOINC+4f4ad2c808_7ae156be3b-r0/image/boot/zImage: > No such file or directory > > > I also see that meta-ti has a bundle-devicetree.inc file that has a similar > aim, but it deals with uImages instead. > > https://git.yoctoproject.org/meta-ti/tree/recipes-kernel/linux/bundle-devicetree.inc > > My concern with using this is that it appends the DTB directly to the uImage. > However the uImage header structure includes a field for data size and > another one for checksum. These fields are only computed correctly if the DTB > is already appended before the uImage file is built. > > > I think if I can figure out how to make KERNEL_DEVICETREE_BUNDLE create the > zImage+DTB file, then I can write a do_deploy:append() function that invokes > mkimage to produce the uImage. But I'm not sure how to diagnose the problem. > > Thanks, > Ryan > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#55902): https://lists.yoctoproject.org/g/yocto/message/55902 Mute This Topic: https://lists.yoctoproject.org/mt/88479144/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Problem installing python package from a wheel #bitbake
On Wed, 2021-11-24 at 09:55 -0800, Tim Orling wrote: > > > On Mon, Nov 22, 2021 at 2:54 PM David Babich > wrote: > > I made it a little further by adding --no-cache-dir to the pip3 > > install command. That got rid fo the warning about not being able > > to access the .cache/pip. However I still have the error: > > | ERROR: torch-1.10.0-cp36-cp36m-linux_aarch64.whl is not a > > supported wheel on this platform. > > > > > > Installing third-party wheels is not something we are likely to ever > support in Yocto Project/OpenEmbedded recipes. > > Are you trying to install using pip3 on target? > Note that many factors will make it tricky for python wheels with > binary content (C or Rust extensions). The python3 version must > match, as will the libraries it requires. > > The wheel you listed was built for Python 3.6 (cp36) and ARM v8 > (aarch64). The error is what you would see if you were trying to > install an aarch64 wheel on an x86-64 target, but other reasons could > lead to that error. We don't know what version of glibc, gcc, etc. > was used and whether those are going to be compatible. > There's a section about building from source with a patch in the article he linked with his first message. I don't know much about python in yocto, but maybe doing that in a recipe could work? > Also, when asking questions, please tell us which release of Yocto > Project you are using, what the MACHINE you are building for is, > which layers you are using (and at what release) and other > information to help us help you. > > Cheers, > --Tim > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#55420): https://lists.yoctoproject.org/g/yocto/message/55420 Mute This Topic: https://lists.yoctoproject.org/mt/87247090/21656 Mute #python:https://lists.yoctoproject.org/g/yocto/mutehashtag/python Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] building the kernel's usbipd daemon
On Fri, 2021-11-05 at 15:02 -0700, chuck kamas via
lists.yoctoproject.org wrote:
> Well it turns out that following the Perf recipe was not only a good
> idea, but absolutely necessary. The perf recipe copies the code out of
> the work-shared kernel directory into the perf build directory. This
> avoids the error when bitbake thinks that the kernel code is not needed
> anymore and removes it.
>
>
> Please see my version of the USBIP recipe below.
>
>
> Question, how does one get this into the recipe database?
>
I'm not sure where this belongs, but maybe you can try to submit it to
the meta-oe repository. Look at the readme[1] for instructions.
[1]: https://git.openembedded.org/meta-openembedded/tree/meta-oe/README
>
> Again thanks for the help!
>
> Chuck
>
> > SUMMARY = "USBip part of Linux kernel built in tools"
> > DESCRIPTION = " USB/IP protocol allows to pass USB device from server
> > to \
> > client over the network. Server is a machine which provides (shares)
> > a \
> > USB device. Client is a machine which uses USB device provided by
> > server \
> > over the network. The USB device may be either physical device
> > connected \
> > to a server or software entity created on a server using USB gadget
> > subsystem."
> >
> > LICENSE = "GPLv2"
> > LIC_FILES_CHKSUM =
> > "file://${COMMON_LICENSE_DIR}/GPL-
> > 2.0;md5=801f80980d171dd6425610833a22dbe6"
> > DEPENDS = "virtual/kernel libtool udev"
> > PROVIDES = "virtual/usbip-tools"
> >
> > inherit linux-kernel-base kernel-arch kernelsrc manpages
> >
> >
> > do_populate_lic[depends] += "virtual/kernel:do_patch"
> > do_configure[depends] += "virtual/kernel:do_shared_workdir"
> >
> > EXTRA_OEMAKE = "\
> > -C ${S}/tools/usb/usbip \
> > O=${B} \
> > CROSS_COMPILE=${TARGET_PREFIX} \
> > CROSS=${TARGET_PREFIX} \
> > CC="${CC}" \
> > CCLD="${CC}" \
> > LD="${LD}" \
> > AR="${AR}" \
> > ARCH="${ARCH}" \
> > TMPDIR="${B}" \
> > "
> >
> > EXTRA_OEMAKE += "\
> > 'DESTDIR=${D}' \
> > KERNEL_SRC=${STAGING_KERNEL_DIR} \
> > "
> >
> > do_configure[depends] += "virtual/kernel:do_shared_workdir"
> >
> > inherit autotools gettext
> >
> > # stolen from autotools.bbclass
> >
> > CONFIGUREOPTS = " --build=${BUILD_SYS} \
> > --host=${HOST_SYS} \
> > --target=${TARGET_SYS} \
> > --prefix=${prefix} \
> > --exec_prefix=${exec_prefix} \
> > --bindir=${bindir} \
> > --sbindir=${sbindir} \
> > --libexecdir=${libexecdir} \
> > --datadir=${datadir} \
> > --sysconfdir=${sysconfdir} \
> > --sharedstatedir=${sharedstatedir} \
> > --localstatedir=${localstatedir} \
> > --libdir=${libdir} \
> > --includedir=${includedir} \
> > --oldincludedir=${oldincludedir} \
> > --infodir=${infodir} \
> > --mandir=${mandir} \
> > --disable-silent-rules \
> > ${CONFIGUREOPT_DEPTRACK} \
> > ${@append_libtool_sysroot(d)} \
> > "
> >
> > do_configure_prepend () {
> > cd ${S}/tools/usb/usbip
> > ./cleanup.sh
> > ./autogen.sh
> > ./configure ${CONFIGUREOPTS} ${EXTRA_OECONF}
> > }
> >
> > do_compile() {
> > oe_runmake
> > }
> >
> > do_install() {
> > oe_runmake DESTDIR=${D} install
> > }
> >
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > python do_package_prepend() {
> > d.setVar('PKGV', d.getVar("KERNEL_VERSION", True).split("-")[0])
> > }
> >
> > B = "${WORKDIR}/${BPN}-${PV}"
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55271): https://lists.yoctoproject.org/g/yocto/message/55271
Mute This Topic: https://lists.yoctoproject.org/mt/86249103/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Enabling Websockets in Mosquitto in yocto zeus #zeus
On Fri, 2021-10-01 at 03:45 -0700, poorn...@elmeasure.com wrote: > Greetings ! > > I could able to add Mosquitto in Yocto Zeus , but as default websockets > is disabled in Mosquitto . Can anyone help me how to enable websockets > in Mosquitto in yocto zeus. > There's a 'websockets' PACKAGECONFIG for the mosquitto recipe. You can read more about how to change PACKAGECONFIGs in the documentation [1]. Be aware that since yocto dunfell, the websockets PACKAGECONFIG is enabled by default, so you can remove it if you update to a newer version in the future. [1]: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-PACKAGECONFIG > Thanks in Advance > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54955): https://lists.yoctoproject.org/g/yocto/message/54955 Mute This Topic: https://lists.yoctoproject.org/mt/85995510/21656 Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Inactive service of hello world #yocto
On Tue, 2021-09-07 at 10:43 -0700, Rudolf J Streif wrote: > What does your 'Hello World' service do? Just print 'Hello World' to > the console and then exit? > > If so that would be the reason why it is inactive. Systemd starts it > and then it exits. Typically, services keep running (except for some > special cases) once they are started. That's what makes them a service. > To stop them 'systemctl stop ' is used. By default systemctl > sends SIGTERM to tell the service to clean up and terminate itself. > To piggyback on that, it is possible to set Type=oneshot[1] for the service so that systemd considers the service to be up after it exited. I find it useful for init or migration scripts that another service can then depend upon. [1]: https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type= > :rjs > > > On Tue, Sep 7, 2021, 10:20 wrote: > > Hi everyone, > > > > I wanted to run the helloworld service, but it keeps telling that its > > inactive , I really cant find why, I changed the service many times > > but no solution. > > I m sorry I ant copy paste from putty > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54677): https://lists.yoctoproject.org/g/yocto/message/54677 Mute This Topic: https://lists.yoctoproject.org/mt/85440335/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] raspberrypi GPIO #raspberrypi
On Wed, 2021-08-18 at 03:59 -0700, yasminebenghoz...@gmail.com wrote: > Hello, > > I have a problem importing python RPi.GPIO in yocto, not found, while > they should be there only by cloning the meta-raspberry right? There is a recipe for RPi.GPIO available in meta-raspberrypi [1]. I doubt that it's installed in any of the default images. You should add it to your image by appending to the IMAGE_INSTALL variable. See the Customizing Images section in the manual [2] for more information. [1]: https://layers.openembedded.org/layerindex/recipe/5769/ [2]: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#usingpoky-extend-customimage > Any answer please on how to get them? > thank you -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54475): https://lists.yoctoproject.org/g/yocto/message/54475 Mute This Topic: https://lists.yoctoproject.org/mt/84969544/21656 Mute #raspberrypi:https://lists.yoctoproject.org/g/yocto/mutehashtag/raspberrypi Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] execute a python code in raspberrypi #python
On Fri, 2021-08-13 at 02:40 -0700, yasminebenghoz...@gmail.com wrote: > Hello beautiful people, > > I successfully executed helloworld.py on the raspberrypi by making a > layer. BUt now i need to add a whole python code with classes etc, > which exists in different files like the picture, I wanna know please > how to add them to be able to run the code on the raspberrypi. THey re > all related together and i need to run the main-SF.py so the code will > be executed. > I recommend putting your whole python project into a repository (e.g. with git) and then create a recipe that fetches the git repository and installs the files to a sensible location. You should be able to follow the documentation on writing a new recipe to some degree: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#new-recipe-writing-a-new-recipe To run your script on boot, I would create an init script / systemd service, depending on what init system your image is using. See here for more information: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#new-recipe-enabling-system-services > THank you . -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54430): https://lists.yoctoproject.org/g/yocto/message/54430 Mute This Topic: https://lists.yoctoproject.org/mt/84859973/21656 Mute #python:https://lists.yoctoproject.org/g/yocto/mutehashtag/python Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] best way to get feature of systemd v248 in yocto-hardknott (systemd v247)?
On Fri, 2021-08-13 at 15:31 -0600, Bill Plunkett wrote: > I'd like to use a systemd DHCP client feature that became available > in v248 in my yocto-hardknott system. Is there any hope of using the > complete v249.1 recipe from the oe master branch? > To backport a newer version, I usually just take the trial and error route by copying the recipe to a custom layer and then, if necessary, resolving missing or outdated dependencies on the go. This works most of the time, but it could get a bit more complicated for systemd if something fundamentally changed. > Bill -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54429): https://lists.yoctoproject.org/g/yocto/message/54429 Mute This Topic: https://lists.yoctoproject.org/mt/84873812/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] (Go) Library for configuring Yocto based boxes?
On Wed, 2021-08-04 at 09:13 +, Christofer Dutz wrote: > Hi, > > it seems that on the yocto buily the vendor of my box provides > (haven't really started customizing this) > both NetworkManager as well as systemd-networkd are installed. This > seems to be bad. In this case you should probably ask your vendor how they set up networking and why they installed both. > > I could find /etc/systemd/network, but this only contained an empty > 99-default.link symlink to /dev/null > The directories /usr/lib/systemd and /run/systemd both exist, but > both don't contain any "network" directory. > > Same with the /etc/NetworkManager/system-connections > > Strangely I have two connections configured: "Wired connection 1" and > "Wired connection 2" which I however don't find any occurence in any > of the files on my system (Except log-files, which mention them) ... > are these configured per default? And if yes ... is systemd-networkd > or NetworkManager defining them? It's possible that your vendor configured something different than the defaults, hard to tell without knowing more. By default the names "Wired connection X" are given by NetworkManager, without any user configuration. I guess NetworkManager is currently managing your connections. > > I think I'll probably go down the route of removing NetworkManager > from the box ... having both seems to be dangerous and the systemd > appears to be more in-line with the modern way oft hings (even if it > might not be as powerful yet) > I started out with systemd-networkd and later replaced it with NetworkManager because I wanted to use a 4G modem with ModemManager, which wasn't well supported by systemd-networkd back then. As long as you only use Ethernet and Wi-Fi, systemd-networkd should work fine. > Chris > > > -Ursprüngliche Nachricht- > Von: Nicolas Jeker > Gesendet: Mittwoch, 4. August 2021 09:05 > An: Christofer Dutz ; > yocto@lists.yoctoproject.org > Betreff: Re: [yocto] (Go) Library for configuring Yocto based boxes? > > On Mon, 2021-08-02 at 11:32 +, Christofer Dutz wrote: > > Hi all, > > > > so I guess this is another case of "I should have posed my question > > earlier, than I would have found the soltion myself" ;-) > > > > So it turns out that: > > > > err = > > propertyConnection.Update(connectionSettings) > > > > Only updates the settings, however it doesn't actiavate the changes > > (This happens on the next boot) ... But if I also run > > > > _, err = > > nm.ActivateConnection(propertyConnection, device, nil) > > > > The changes seem to be applied instantly :-) > > > > Glad to hear it works. > > > So I guess I'm now safe and managed to get the things I needed > > working. > > > > I had a look and NetworkManager doesn't seem to be running, I can > > find > > a process systemd-networkd however, so I guess everything is setup > > correctly. I also used the nmcli to experiment. > > > > Do I understand it correctly, is systemd-networkd a different > > implementation of the same service as NetworkManager? Because I can > > see the configs beeing written to "/etc/NetworkManager/system- > > connections"? > > > > This doesn't sound correct. It's already some time ago that I last > worked on networking. As far as I remember, systemd-networkd and > NetworkManager are working differently: > > Configuration files > --- > systemd-networkd uses *.network files in /usr/lib/systemd/network, > /run/systemd/network and /etc/systemd/network > > NetworkManager uses *.nm-connection files in > /etc/NetworkManager/system-connections (and maybe others that I'm not > aware of) > > Command line utility > > > systemd-networkd can be controlled with networkctl NetworkManager can > be controlled with nmcli > > > I'm not sure why your setup even works, maybe I'm missing something. > For further reading I can recommend the ArchWiki pages (they don't > always apply perfectly to Yocto, but it's close enough and very > detailed) and the respective man pages: > > https://wiki.archlinux.org/title/Systemd-networkd > https://wiki.archlinux.org/title/NetworkManager > https://man.archlinux.org/man/systemd-networkd.8 > https://man.archlinux.org/man/extra/networkmanager/NetworkManager.8.en > > > Chris > > > > > > > > -Ursprüngliche Nachricht- > > Von: Nicola
Re: [yocto] (Go) Library for configuring Yocto based boxes?
On Mon, 2021-08-02 at 11:32 +, Christofer Dutz wrote:
> Hi all,
>
> so I guess this is another case of "I should have posed my question
> earlier, than I would have found the soltion myself" ;-)
>
> So it turns out that:
>
> err =
> propertyConnection.Update(connectionSettings)
>
> Only updates the settings, however it doesn't actiavate the changes
> (This happens on the next boot) ... But if I also run
>
> _, err =
> nm.ActivateConnection(propertyConnection, device, nil)
>
> The changes seem to be applied instantly :-)
>
Glad to hear it works.
> So I guess I'm now safe and managed to get the things I needed working.
>
> I had a look and NetworkManager doesn't seem to be running, I can find
> a process systemd-networkd however, so I guess everything is setup
> correctly. I also used the nmcli to experiment.
>
> Do I understand it correctly, is systemd-networkd a different
> implementation of the same service as NetworkManager? Because I can see
> the configs beeing written to "/etc/NetworkManager/system-connections"?
>
This doesn't sound correct. It's already some time ago that I last
worked on networking. As far as I remember, systemd-networkd and
NetworkManager are working differently:
Configuration files
---
systemd-networkd uses *.network files in /usr/lib/systemd/network,
/run/systemd/network and /etc/systemd/network
NetworkManager uses *.nm-connection files in
/etc/NetworkManager/system-connections (and maybe others that I'm not
aware of)
Command line utility
systemd-networkd can be controlled with networkctl
NetworkManager can be controlled with nmcli
I'm not sure why your setup even works, maybe I'm missing something.
For further reading I can recommend the ArchWiki pages (they don't
always apply perfectly to Yocto, but it's close enough and very
detailed) and the respective man pages:
https://wiki.archlinux.org/title/Systemd-networkd
https://wiki.archlinux.org/title/NetworkManager
https://man.archlinux.org/man/systemd-networkd.8
https://man.archlinux.org/man/extra/networkmanager/NetworkManager.8.en
> Chris
>
>
>
> -Ursprüngliche Nachricht-
> Von: Nicolas Jeker
> Gesendet: Montag, 2. August 2021 13:18
> An: Christofer Dutz ;
> yocto@lists.yoctoproject.org
> Betreff: Re: [yocto] (Go) Library for configuring Yocto based boxes?
>
> On Mon, 2021-08-02 at 09:35 +, Christofer Dutz wrote:
> > Hi all,
> >
> > so I invested quite some time to using the NetworkManager to
> > configure
> > the network settings.
> > I’m using a go library: github.com/Wifx/gonetworkmanager for this.
> > My network configurations now end up in a directory
> > /etc/NetworkManager/system-connections (I can see files with the name
> > "{connection-id}.nmconnection"
> > However the changes aren't applied. If I run:
> >
> > systemctl restart systemd-networkd
> >
>
> systemd-networkd and NetworkManager are two different things. Make sure
> that you only have one of them running at the same time.
>
> A quick solution is to use systemd to disable the systemd-networkd
> service (if that's not already the case). What I did as a more long-
> term solution is removing systemd-networkd in my distro.conf (works in
> local.conf, too):
>
> PACKAGECONFIG_remove_pn-systemd = "networkd"
>
> > The network settings don't change (Both network devices were set to
> > DHCP). (By the way … where can I see the default configuration?)
> >
>
> I'm currently using nmcli to set my configuration and apply it with:
>
> nmcli con up {connection-id}
>
> This works for me even if the connection status is already "up". Not
> sure if it works when you replace the configuration file, but you might
> give it a try. Otherwise restarting NetworkManager should work:
>
> systemctl restart NetworkManager
>
> > However if I reboot the box, I can see my changes applied ... until I
> > run the "systemctl restart systemd-networkd" again, because then it
> > switches back to the dhcp settings.
>
> I suspect this happens because systemd-networkd "overrides" the
> interface configuration that was set by NetworkManager.
>
> > Any tips on how I can apply my changes without rebooting?
> >
> > Chris
> >
> >
> > -Ursprüngliche Nachricht-
> > Von: Nicolas Jeker
> > Gesendet: Freitag, 30. Juli 2021 10:06
> > An: Christofer Dutz ;
> > yocto@lists.yoctoproject.org
> > Betreff: Re: [yocto] (Go)
Re: [yocto] (Go) Library for configuring Yocto based boxes?
On Mon, 2021-08-02 at 09:35 +, Christofer Dutz wrote:
> Hi all,
>
> so I invested quite some time to using the NetworkManager to configure
> the network settings.
> I’m using a go library: github.com/Wifx/gonetworkmanager for this.
> My network configurations now end up in a directory
> /etc/NetworkManager/system-connections (I can see files with the name
> "{connection-id}.nmconnection"
> However the changes aren't applied. If I run:
>
> systemctl restart systemd-networkd
>
systemd-networkd and NetworkManager are two different things. Make sure
that you only have one of them running at the same time.
A quick solution is to use systemd to disable the systemd-networkd
service (if that's not already the case). What I did as a more long-
term solution is removing systemd-networkd in my distro.conf (works in
local.conf, too):
PACKAGECONFIG_remove_pn-systemd = "networkd"
> The network settings don't change (Both network devices were set to
> DHCP). (By the way … where can I see the default configuration?)
>
I'm currently using nmcli to set my configuration and apply it with:
nmcli con up {connection-id}
This works for me even if the connection status is already "up". Not
sure if it works when you replace the configuration file, but you might
give it a try. Otherwise restarting NetworkManager should work:
systemctl restart NetworkManager
> However if I reboot the box, I can see my changes applied ... until I
> run the "systemctl restart systemd-networkd" again, because then it
> switches back to the dhcp settings.
I suspect this happens because systemd-networkd "overrides" the
interface configuration that was set by NetworkManager.
> Any tips on how I can apply my changes without rebooting?
>
> Chris
>
>
> -Ursprüngliche Nachricht-
> Von: Nicolas Jeker
> Gesendet: Freitag, 30. Juli 2021 10:06
> An: Christofer Dutz ;
> yocto@lists.yoctoproject.org
> Betreff: Re: [yocto] (Go) Library for configuring Yocto based boxes?
>
> On Fri, 2021-07-30 at 07:43 +, Christofer Dutz wrote:
> > Hi all,
> >
> > I’m very new to the Yocto world.
> >
> > We are currently working on migrating away from OpenWRT based edge
> > devices towards ones that we now have Yocto builds for.
> >
> > All seems to be working nicely on the yocto side.
> >
> > Our application uses a baseline configuration in order to connect
> > to
> > our cloud service and there it fetches it’s configuration (We’ve
> > got a
> > cellular fallback if connectivity doesn’t work at all).
> >
> > With OpenWRT there was a tool called UCI which even had a Go
> > wrapper
> > which we used to apply the configuration to the box (set IP
> > addresses,
> > connect to WiFi neworks, configure the serial ports etc.)
> >
> > Is there some equivalent in the Yocto world?
> >
>
> The OpenWRT wiki has a section on porting UCI to different linux
> distributions [1], but you can probably skip that completely.
> Searching for UCI in the recipe index [2] yields a result from the
> meta-openwrt [3] layer. I would start with adding that layer and
> using the UCI recipe from there.
>
> [1]: https://openwrt.org/docs/techref/uci#usage_outside_of_openwrt
> [2]:
> https://layers.openembedded.org/layerindex/branch/master/recipes/?q=uci
> [3]: https://github.com/kraj/meta-openwrt
>
> > I would like to avoid generating the file content in the /etc
> > directory by hand and firing „restart“ commands to the
> > corresponding
> > services, if there isn’t a better way.
> >
> > Help greatly appreciated :-)
> >
> > Chris
> >
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54277): https://lists.yoctoproject.org/g/yocto/message/54277
Mute This Topic: https://lists.yoctoproject.org/mt/84545913/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] (Go) Library for configuring Yocto based boxes?
On Fri, 2021-07-30 at 07:43 +, Christofer Dutz wrote: > Hi all, > > I’m very new to the Yocto world. > > We are currently working on migrating away from OpenWRT based edge > devices towards ones that we now have Yocto builds for. > > All seems to be working nicely on the yocto side. > > Our application uses a baseline configuration in order to connect to > our cloud service and there it fetches it’s configuration (We’ve got a > cellular fallback if connectivity doesn’t work at all). > > With OpenWRT there was a tool called UCI which even had a Go wrapper > which we used to apply the configuration to the box (set IP addresses, > connect to WiFi neworks, configure the serial ports etc.) > > Is there some equivalent in the Yocto world? > The OpenWRT wiki has a section on porting UCI to different linux distributions [1], but you can probably skip that completely. Searching for UCI in the recipe index [2] yields a result from the meta-openwrt [3] layer. I would start with adding that layer and using the UCI recipe from there. [1]: https://openwrt.org/docs/techref/uci#usage_outside_of_openwrt [2]: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=uci [3]: https://github.com/kraj/meta-openwrt > I would like to avoid generating the file content in the /etc directory > by hand and firing „restart“ commands to the corresponding services, if > there isn’t a better way. > > Help greatly appreciated :-) > > Chris > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54266): https://lists.yoctoproject.org/g/yocto/message/54266 Mute This Topic: https://lists.yoctoproject.org/mt/84545913/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #yocto
On Thu, 2021-07-22 at 23:26 -0700, sateesh m wrote: > Hi Guys, > > I am facing below error while compiling consul package. > can anybody know this issue please suggest me. > ERROR: consul-git-r0 do_compile: Execution of '/home/sources/fu540- > build/tmp-glibc/work/riscv64-oe-linux/consul/git- > r0/temp/run.do_compile.26832' failed with exit code 2: > internal/unsafeheader > unicode/utf16 > container/list > internal/cpu > > # github.com/hashicorp/consul/vendor/golang.org/x/sys/unix > src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_ > linux_gc.go:10:6: missing function body > src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_ > linux_gc.go:14:6: missing function body > src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_ > unix_gc.go:12:6: missing function body > src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_ > unix_gc.go:13:6: missing function body > src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_ > unix_gc.go:14:6: missing function body > src/github.com/hashicorp/consul/vendor/golang.org/x/sys/unix/syscall_ > unix_gc.go:15:6: missing function body Searching for these error messages I found a comment on GitHub [1] which states that this is caused by missing assembly syscall wrappers. Experimental support for RISC-V was added in Go 1.14 [2] and improved in the next two versions, so make sure you use at least 1.14. If the problem persists, I suggest to ask in a dedicated RISC-V or Go forum/mailing list/chat. I don't have any experience with Go or RISC-V, so take this information with a grain of salt. [1]: https://github.com/golang/go/issues/27532#issuecomment-493384077 [2]: https://golang.org/doc/go1.14#riscv > net/http/pprof > WARNING: exit code 2 from a shell command. > > ERROR: Logfile of failure stored in: /home/sources/fu540-build/tmp- > glibc/work/riscv64-oe-linux/consul/git-r0/temp/log.do_compile.26832 > > -- > Regards, > Sateesh -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54236): https://lists.yoctoproject.org/g/yocto/message/54236 Mute This Topic: https://lists.yoctoproject.org/mt/84395975/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Improving NPM recipe build speed
On Mon, 2021-04-26 at 16:29 -0700, Alessandro Tagliapietra wrote: > Hi everyone, Hi Alessandro, > I'm making an image that includes the node-red recipe from meta-iot- > cloud. > The whole process takes about 30+ minutes for that recipe alone (most > of the time spent in do_configure). > Now I want to override the recipe systemd service file and create a > nodered user. Every time I change my bbappend file I have to wait 30+ > minutes to have the result even for a small systemd file change. > > Is it possible to speed up the process somehow? > I never worked with node-red in yocto, so I can't speak specifically for that, but I encountered similar situations before. Here is what I usually do when I need to change a file in a recipe that takes a really long time to compile or triggers a rebuild of a ton of other recipes. This only works for files that don't need to be compiled, like configuration files, systemd service files, udev rules etc. I usually replace the file in the rootfs directly on the device (or boot from NFS and edit the file in the NFS export). For example if I need to change a systemd service file, I change the file on my host, copy it with scp to the device and check if everything is working as expected. When I'm finished, I reintegrate my edits with a bbappend file and check again if it works. > Thanks in advance -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53431): https://lists.yoctoproject.org/g/yocto/message/53431 Mute This Topic: https://lists.yoctoproject.org/mt/82392305/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Wrong OELAYOUT_ABI in poky dunfell 3.1.6 suppresses message
Hi all, I recently upgraded my project from dunfell 3.1.5 to 3.1.6 and saw errors about pseudo path mismatches on various build machines. Removing TMPDIR solved the problem, but I did some digging to see if I find the source of the problem. First of all: The wiki page about pseudo aborts [1] is generally a good thing, I hope it gets higher into search machines result lists as time passes (a week ago I didn't find it at all, now it's result #4 on Google for "yocto exit code 134" which is okay). Second, a nice message was added to sanity.bbclass that the user should clean the TMPDIR and rebuild. Sadly, an override of the OELAYOUT_ABI variable in meta-poky/conf/distro/poky.conf suppressed this message for dunfell 3.1.6. It's fixed in the branch for 3.1.7 (the offending code was removed). # $OELAYOUT_ABI [2 operations] # set /workdir/build/../layers/poky/meta/conf/abi_version.conf:7 # "14" # set /workdir/build/../layers/poky/meta- poky/conf/distro/poky.conf:76 # "12" # pre-expansion value: # "12" OELAYOUT_ABI="12" Maybe we should add a section about that bug which suppresses the message and that emptying the TMPDIR is recommended when updating to 3.1.6 from an older release to the wiki page? I haven't checked if this also affects other versions. [1]: https://wiki.yoctoproject.org/wiki/Pseudo_Abort -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53170): https://lists.yoctoproject.org/g/yocto/message/53170 Mute This Topic: https://lists.yoctoproject.org/mt/82208141/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to get packages version from an image recipe #yocto #linux
Hi Zakaria On Thu, 2021-02-11 at 03:47 -0800, zakaria.zid...@smile.fr wrote: > Hello, > > I want to get the version of the packages generated by a recipe from > the image recipe (or by a python script that runs outside of the > package generating recipe). (like the output of the bitbake -s > command) > > Do you have any ideas please? Probably the image manifest is what you are looking for? From https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#image-generation-dev-environment : The manifest file (.manifest) resides in the same directory as the root filesystem image. This file lists out, line-by-line, the installed packages. The file contents look like this: ... dropbear armv7at2hf-neon 2019.78-r0 dtc armv7at2hf-neon 1.6.0-r0 e2fsprogs armv7at2hf-neon 1.45.4-r0 ... > Thank you -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52301): https://lists.yoctoproject.org/g/yocto/message/52301 Mute This Topic: https://lists.yoctoproject.org/mt/80555263/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto 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] Duplictae files gets created on opening any file in yocto for rpi cm3 #cm3 #dunfell
On Tue, 2021-02-09 at 21:22 -0800, prashantsi...@dialtronics.com wrote: > Dear team, > > I'm using yocto-dunfell for generating for my rpi-cm3. > it is working fine, but one issue I'm facing that when ever I'm > trying to open any file, that gets duplicated with it's name and then > ~ sign. > e.g. I'm open hello.sh file, then on saving this file one file will > be automatically generated with the name hello.sh~ . > This thing unnecessarily consuming memory in my file-system. Are you using vim to edit the files? If yes, then take a look at "backup files": https://vimhelp.org/editing.txt.html#backup Be aware that vim possibly creates swap and undo files, too. https://vimhelp.org/recover.txt.html#swap-file https://vimhelp.org/undo.txt.html#undo-persistence > Please assist me some method to get rid with this. > > Thanks and Regards. > Prashant Singh > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52284): https://lists.yoctoproject.org/g/yocto/message/52284 Mute This Topic: https://lists.yoctoproject.org/mt/80525481/21656 Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell Mute #cm3:https://lists.yoctoproject.org/g/yocto/mutehashtag/cm3 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] RT patch for 5.4.74?
On Thu, 2021-02-04 at 17:39 -0500, jchludzinski via lists.yoctoproject.org wrote: > From Altera/Intel? > > On 2021-02-04 17:20, jchludzinski via lists.yoctoproject.org wrote: > > Is there an RT patch for 5.4.74? > > (I've used patch-5.4.44-rt27.patch.) This is the official download page for the RT patches: https://wiki.linuxfoundation.org/realtime/preempt_rt_versions There is also a section about which patches are actively maintained. As written on this page, the archive with all RT patches is located here: https://cdn.kernel.org/pub/linux/kernel/projects/rt/ You can find a matching patch for your version in the 5.4/older directory. Be aware that the newest 5.4 LTS kernel is 5.4.95. If possible I would try to upgrade to this version. > > ---John -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52242): https://lists.yoctoproject.org/g/yocto/message/52242 Mute This Topic: https://lists.yoctoproject.org/mt/80392613/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-virtualization]: dunfell docker run issues
On Thu, 2021-02-04 at 16:03 +0100, Marek Belisko wrote: > Hi, > I'm trying to run docker containers on orangepi and use > meta-virtualization layer to add docker. I've installed the docker-ce > package and everything seems to be fine. > > But docker service seems fails to start with: > Feb 04 15:00:01 orange-pi-zero dockerd[495]: failed to start daemon: > Devices cgroup isn't mounted Is your kernel actually configured with cgroups support? You need CONFIG_CGROUPS and many of the child configs. From your error message I suspect you're missing CONFIG_CGROUP_DEVICE, but that's just an educated guess. Maybe take a look at the Gentoo wiki to see which CONFIG's need to be set (just disregard the Gentoo specifics): https://wiki.gentoo.org/wiki/Docker#Kernel These are the CGROUP-related configs: Menuconfig: General setup ---> [*] POSIX Message Queues -*- Control Group support ---> [*] Memory controller [*] Swap controller [*] Swap controller enabled by default [*] IO controller [ ] IO controller debugging [*] CPU controller ---> [*] Group scheduling for SCHED_OTHER [*] CPU bandwidth provisioning for FAIR_GROUP_SCHED [*] Group scheduling for SCHED_RR/FIFO [*] PIDs controller [*] Freezer controller [*] HugeTLB controller [*] Cpuset controller [*] Include legacy /proc//cpuset file [*] Device controller [*] Simple CPU accounting controller [*] Perf controller [ ] Example controller > I was trying to add various options to kernel command line like > described here: https://github.com/docker/cli/issues/2104 > > but it doesn't work. My command-line looks like: > ...systemd.unified_cgroup_hierarchy=0 cgroup_enable=memory > cgroup_memory=1 swapaccount=1 cgroup_no_v1=all > > Any other ideas what to check? Thanks a lot. > > BR, > > marek -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52241): https://lists.yoctoproject.org/g/yocto/message/52241 Mute This Topic: https://lists.yoctoproject.org/mt/80381272/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #yocto #kernel #zeus
On Fri, 2020-12-04 at 12:17 +, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:
>
> I seem to have an issue initializing busybox.
> I have attached my error log… but basically busybox fails to compile
> when I set
>
> CONFIG_FEATURE_MOUNT_NFS=y
>
The log indicates that it is missing a dependency which ships
"rpc/rpc.h". Some googling turned up this discussion on the
openembedded-core mailing list:
https://lists.openembedded.org/g/openembedded-core/topic/72355602#111216
There is a final patch in the last mail of the topic, but it seems that
this config option is anyway only required for Linux < 2.6.23.
> If I modify my_cfg.cfg and remove the above parameter it compiles
> clean ,
> (I.E. “# CONFIG_FEATURE_MOUNT_NFS is not set”).
>
> I am assuming my bbappend file is at fault, but do not see it. This
> setup works correctly under “rocko”, and if I disable
> “CONFIG_FEATURE_MOUNT_NFS” all appears correct…
>
> Can someone tell me what is going on and how to correct ?
>
> Thanks,
> Steve
>
> This is my append file:
>
> busybox_%.bbappend:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> FILESEXTRAPATHS_prepend := "${THISDIR}/busybox:"
>
> SRC_URI_append += " \
> file://inetd.conf \
> file:// my_cfg.cfg \
> file://ftp.cfg \
> file://ftpd.cfg \
> file://hexdump.cfg \
> file://httpd.cfg \
> file://inetd.cfg \
> file://nc.cfg \
> file://telnetd.cfg \
> file://tftpd.cfg \
> file://coreutils.cfg \
> "
>
> PACKAGES =+ "${@plnx_enable_busybox_package('inetd', d)}"
>
> INITSCRIPT_PACKAGES =+ "${@plnx_enable_busybox_package('inetd', d)}"
>
> FILES_${PN}-inetd = "${sysconfdir}/init.d/busybox-inetd
> ${sysconfdir}/inetd.conf"
> INITSCRIPT_NAME_${PN}-inetd = "inetd.busybox"
> INITSCRIPT_PARAMS_${PN}-inetd = "start 65 S ."
> CONFFILES_${PN}-inetd = "${sysconfdir}/inetd.conf"
>
> RRECOMMENDS_${PN} =+ "${@bb.utils.contains('DISTRO_FEATURES',
> 'busybox-inetd', '${PN}-inetd', '', d)}"
>
> def plnx_enable_busybox_package(f, d):
> distro_features = (d.getVar('DISTRO_FEATURES', True) or
> "").split()
> if "busybox-" + f in distro_features:
> return "${PN}-" + f
> else:
> return ""
>
> This is my platform specific config file:
>
> my_cfg.cfg:
>
> CONFIG_EXTRA_COMPAT=y
> CONFIG_INCLUDE_SUSv2=y
> CONFIG_FEATURE_VERBOSE_USAGE=y
> CONFIG_UNICODE_SUPPORT=y
> CONFIG_NICE=y
> CONFIG_SHA512SUM=y
> CONFIG_MKFS_VFAT=y
> CONFIG_FEATURE_TOP_SMP_CPU=y
> CONFIG_FEATURE_TOP_DECIMALS=y
> CONFIG_FEATURE_TOP_SMP_PROCESS=y
> CONFIG_FEATURE_TOPMEM=y
> CONFIG_FEATURE_MOUNT_VERBOSE=y
> CONFIG_FEATURE_MOUNT_HELPERS=y
> CONFIG_FEATURE_MOUNT_NFS=y <<<- if disabled, compiles clean
> CONFIG_FEATURE_MOUNT_CIFS=y
> CONFIG_WATCHDOG=y
> CONFIG_DEVMEM=y
> CONFIG_LSPCI=y
> # CONFIG_GZIP is not set
> # CONFIG_GUNZIP is not set
> # CONFIG_UNZIP is not set
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51642): https://lists.yoctoproject.org/g/yocto/message/51642
Mute This Topic: https://lists.yoctoproject.org/mt/78707583/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #kernel:https://lists.yoctoproject.org/g/yocto/mutehashtag/kernel
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #yocto
Hi Steve On Tue, 2020-12-01 at 20:06 +, Monsees, Steven C (US) via lists.yoctoproject.org wrote: > > I still haven’t been able to track this down, can someone tell me in > what package is the banner output generated ? I'm not sure to what lines you refer by "banner", so I just wrote my thoughts to both below. Both are probably produced by getty, either util-linux-agetty or systemd-getty. > Thanks, > Steve > From: yocto@lists.yoctoproject.org [mailto: > yocto@lists.yoctoproject.org]On Behalf Of Monsees, Steven C (US) via > lists.yoctoproject.org > Sent: Wednesday, November 18, 2020 8:08 AM > To: yocto@lists.yoctoproject.org > Subject: [yocto] #yocto > > ***WARNING*** > EXTERNAL EMAIL -- This message originates from outside our > organization. > > > I was going through the kernel boot output and saw the following > output, can someone tell me why this might be popping up and how I > might modify configuration to resolve? : > . > . > LIMWS (BAE LIMWS base distro) 3.0.4 sbcb-default ttyS0 This "banner" output is the content of /etc/issue (which gets installed by the base-file package). > -sh: cannot set terminal process group (1137): Inappropriate ioctl > for device > -sh: no job control in this shell > . The error you see about the shell is probably getty failing to open a shell. Maybe this could be relevant: https://unix.stackexchange.com/questions/338214/error-trying-to-run-agetty-in-a-runit-based-linux-installation > . > > Thanks, > Steve -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51611): https://lists.yoctoproject.org/g/yocto/message/51611 Mute This Topic: https://lists.yoctoproject.org/mt/78339652/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to add python application into the build. #python #toolchain
On Tue, 2020-11-24 at 04:33 -0800, vijayrakeshmunga...@gmail.com wrote: > Hi, Hi Vijay > I'm new to the Yocto Project, trying to include my python application > into the build. Can anyone guide me how to write a bitbake recipe .bb > file or any example recipe would be helpful. Reading and following the section about "Writing a New Recipe" in the manual is probably a good starting point: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#new-recipe-writing-a-new-recipe I usually look at related recipes that already exist (in your case some other python recipe) and try to start with a minimal recipe and fix build errors/missing dependencies/etc. iteratively. > Thank & Regards, > Vijay. > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51544): https://lists.yoctoproject.org/g/yocto/message/51544 Mute This Topic: https://lists.yoctoproject.org/mt/78475601/21656 Mute #python:https://lists.yoctoproject.org/g/yocto/mutehashtag/python Mute #toolchain:https://lists.yoctoproject.org/g/yocto/mutehashtag/toolchain Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] KeyError: 'getpwuid(): uid not found: 1000' in do_package phase
On Mon, 2020-11-16 at 23:27 +0100, Martin Jansa wrote:
> https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
>
> is an example where it triggers this error, but doesn't trigger the
> more common host-user-contaminated QA error (unless you happened to
> use UID 1001 on host for the user running bitbake).
>
> Similarly when the files are "installed" with e.g. "cp -a" for which
> layers usually use "cp -R --no-dereference --preserve=mode,links -v".
On a related note, the do_install reference in the manual gives some
advice on how to use cp and tar without contaminating the build.
The relevant part:
Safe methods for installing files include the following:
* The install utility. This utility is the preferred method.
* The cp command with the "--no-preserve=ownership" option.
* The tar command with the "--no-same-owner" option. See the
bin_package.bbclass file in the meta/classes directory of the
Source Directory for an example.
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-tasks-install
> On Mon, Nov 16, 2020 at 10:10 PM Marek Belisko <
> marek.beli...@gmail.com> wrote:
> > On Mon, Nov 16, 2020 at 9:52 PM Joshua Watt
> > wrote:
> > >
> > >
> > > On 11/16/20 2:38 PM, Marek Belisko wrote:
> > >
> > > Hi,
> > >
> > > I'm bumping my project based on zeus to dunfell. I've update all
> > > layers and in one of my recipes I'm seeing following issue (not
> > see on
> > > zeus at all):
> > > WARNING: cv-my-test-1.0-r0 do_package: KeyError in
> > ./package/srv/10%.png
> > > ERROR: cv-my-test-1.0-r0 do_package: 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:sstate_report_unihash(d)
> > > 0003:
> > > File: '/home/ubuntu/projects/my-test-
> > /poky/meta/classes/sstate.bbclass',
> > > lineno: 840, function: sstate_report_unihash
> > > 0836: report_unihash = getattr(bb.parse.siggen,
> > 'report_unihash', None)
> > > 0837:
> > > 0838: if report_unihash:
> > > 0839: ss = sstate_state_fromvars(d)
> > > *** 0840: report_unihash(os.getcwd(), ss['task'], d)
> > > 0841:}
> > > 0842:
> > > 0843:#
> > > 0844:# Shell function to decompress and prepare a package
> > for installation
> > > File: '/home/ubuntu/projects/my-test-
> > /poky/bitbake/lib/bb/siggen.py',
> > > lineno: 555, function: report_unihash
> > > 0551:
> > > 0552: if "." in self.method:
> > > 0553: (module, method) =
> > self.method.rsplit('.', 1)
> > > 0554: locs['method'] =
> > > getattr(importlib.import_module(module), method)
> > > *** 0555: outhash =
> > bb.utils.better_eval('method(path,
> > > sigfile, task, d)', locs)
> > > 0556: else:
> > > 0557: outhash =
> > bb.utils.better_eval(self.method +
> > > '(path, sigfile, task, d)', locs)
> > > 0558:
> > > 0559: try:
> > > File: '/home/ubuntu/projects/my-test-
> > /poky/bitbake/lib/bb/utils.py',
> > > lineno: 420, function: better_eval
> > > 0416: if extraglobals:
> > > 0417: ctx = copy.copy(ctx)
> > > 0418: for g in extraglobals:
> > > 0419: ctx[g] = extraglobals[g]
> > > *** 0420: return eval(source, ctx, locals)
> > > 0421:
> > > 0422:@contextmanager
> > > 0423:def fileslocked(files):
> > > 0424: """Context manager for locking and unlocking file
> > locks."""
> > > File: '', lineno: 1, function:
> > > File "", line 1, in
> > >
> > > File: '/home/ubuntu/projects/my-test-
> > /poky/meta/lib/oe/sstatesig.py',
> > > lineno: 595, function: OEOuthashBasic
> > > 0591: process(root)
> > > 0592: for f in files:
> > > 0593: if f == 'fixmepath':
> > > 0594: continue
> > > *** 0595: process(os.path.join(root, f))
> > > 0596: finally:
> > > 0597: os.chdir(prev_dir)
> > > 0598:
> > > 0599: return h.hexdigest()
> > > File: '/home/ubuntu/projects/my-test-
> > /poky/meta/lib/oe/sstatesig.py',
> > > lineno: 551, function: process
> > > 0547: add_perm(stat.S_IXOTH, 'x')
> > > 0548:
> > > 0549: if include_owners:
> > > 0550: try:
> > > *** 0551: update_hash(" %10s" %
> > > pwd.getpwuid(s.st_uid).pw_name)
> > > 0552: update_hash(" %10s" %
> > > grp.getgrgid(s.st_gid).gr_name)
> > > 0553: except KeyError:
> > > 0554: bb.warn("KeyError in %s" %
> > path)
> > > 0555: rai
Re: [yocto] Yocto recipe for Tailscale #yocto #golang
Hi Mike, On Thu, 2020-09-17 at 22:43 -0700, Mike Thompson via lists.yoctoproject.org wrote: > Does anyone know if there is an existing bitbake recipe for building > the Tailscale client daemon and CLI tool from the following source? > A search on Google yielded no obvious links. > > https://github.com/tailscale/tailscale I usually search on the OpenEmbedded layer index: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=tailscale Seems like you are right, there seems to be no recipe available. Be aware that not all recipes/layers are listed there, but the majority are. > > The Tailscale client for Linux looks to be built using the Go > language which is a complete unknown to me. I've built very simple > recipes before for basic Makefile and Automake built software, but I > suppose Go brings a new set of challenges. > > If an existing recipe is not available, any words of wisdom before I > get started on this? I never used Go in the Yocto/OpenEmbedded environment, but I'm sure somebody else who has more experience will be able to help. To get started with writing a new recipe I usually get my inspiration from similar recipes (similar language, build system, dependencies, etc.). > Thanks, > > Mike Thompson -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50722): https://lists.yoctoproject.org/g/yocto/message/50722 Mute This Topic: https://lists.yoctoproject.org/mt/76925556/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Mute #golang:https://lists.yoctoproject.org/g/yocto/mutehashtag/golang Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Which recipe for Linux tools to run u-boot command inside Linux?
On Thu, 2020-04-30 at 16:34 +1000, JH wrote: > Hi Yann, > > Thanks for the tips, I have run to add libubootenv, but got so many > errors, I can build a good Yocto image before adding libubootenv, > what > was it going on? Does that mean I need to add all kernel modules and > to rebuild kernel configure? Hi JH, on Zeus it's very likely _not_ libubootenv that you need, you should try to install u-boot-fw-utils. As Yann wrote, the tools are in libubootenv since Dunfell, which is newer than Zeus. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49277): https://lists.yoctoproject.org/g/yocto/message/49277 Mute This Topic: https://lists.yoctoproject.org/mt/73322952/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Patching submodules
On Thu, 2020-03-19 at 23:10 -0500, Emily wrote:
> Hi all -
>
> I have a recipe that I'd like to patch - the source is in a repo
> which has a submodule, and the patch occurs in the submodule. Is
> there a way I can apply this patch without getting an error? I do
> kind of understand why it's a problem - the patch is changing the
> pointer of the submodule to a commit which doesn't actually exist. Do
> I need to build the submodule as a separate recipe and patch it
> separately maybe?
Is there a reason why you don't use a bbappend file with your patch in
it in a custom layer?
Something like this:
package_ver.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://abc.patch"
With this directory structure:
meta-custom-layer
├── package_ver.bbappend
└── package
└── abc.patch
Replace "package" and "ver" with the correct values (if you don't want
to set the version you can use "%" as a wildcard).
Maybe I missed something about your submodule situation and my advice
is completely wrong, if so, just disregard it.
> I used devtool for the patch and if I don't run the devtool reset
> command, then everything builds, but I think this is just because the
> workspace created by devtool was added as a layer, which probably
> isn't a good long term solution.
You should be able to get the above structure by using 'devtool finish
recipe meta-custom-layer'. If that doesn't work you can do it manually
as described above.
> The error I get (pasted below) says I can "enforce with -f" but I'm
> not sure where that option goes exactly. Thanks for the help!
>
> Emily
>
> Error on build:
> ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch:
> Command Error: 'quilt --quiltrc
> /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-
> linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-
> native/etc/quiltrc push' exited with 0 Output:
> Applying patch 0001-Update-Poverty-to-point-to-boost-python3.patch
> File Poverty is not a regular file -- refusing to patch
> 1 out of 1 hunk ignored -- rejects in file
> Patch 0001-Update-Poverty-to-point-to-boost-python3.patch does not
> apply (enforce with -f)
> ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch:
> Function failed: patch_do_patch
I don't know why this error occurs, maybe someone else knows more.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#48871): https://lists.yoctoproject.org/g/yocto/message/48871
Mute This Topic: https://lists.yoctoproject.org/mt/7209/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Uboot NetBoot IMX8
On Wed, 2020-03-11 at 00:39 +, Trevor wrote: > > Mar 11 00:21:16 b2qt-b9-imx8mq mount[2611]: mount: only root can > > use "--types" option (effective UID is 1000) > > > The mount error seems prevalent across all the errors. somehow UID > is 1000 when it should be 0 during boot? By googling the error message I found a thread where somebody has the same question, but I wouldn't recommend following the advice there (running the yocto build as root). How do you extract the root filesystem to your NFS directory? Maybe something is wrong there and the files get extracted with UID 1000 as owner. For reference, I use this command which seems to work fine: sudo tar --strip-components=1 -C /srv/nfs/rootfs -xf images/apalis- imx6-mainline/Apalis-iMX6-Mainline_Image.rootfs.tar.xz Also check that there are no setuid/setgid bits set. > On the Host side, here are the /etc/exports options for NFS: > *(rw,sync,insecure,no_subtree_check,no_root_squash) I'm using pretty much the same NFS options, the only difference I could spot is an additional 'fsid=root' in my exports which is NFSv4 specific. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48733): https://lists.yoctoproject.org/g/yocto/message/48733 Mute This Topic: https://lists.yoctoproject.org/mt/71869845/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
