Trying to add the Debian package libsystemd. But I keep get the following error after, not sure how to solve this.
ERROR: Nothing PROVIDES 'libsystemd' (but example.bb DEPENDS on or otherwise requires it). Close matches:
libteam
systemd
systemd RPROVIDES libsystemd
NOTE: Runtime target 'example' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['example', 'libsystemd']
Missing or unbuildable dependency chain was: [ 'example', 'libsystemd']
fatal error: systemd/sd-daemon.h: No such file or directory | 16 | #include <systemd/sd-daemon.h>
Related post: Yocto Build Dependency on Debian Package
example.bb
DESCRIPTION = "Example Utilities"
LICENSE = "CLOSED"
inherit cmake systemd useradd
require common.inc
S = "${WORKDIR}/git/example-server"
DEPENDS = "simple-web-server boost sqlite3 libsystemd"
systemd/sd-daemon.h is provided by systemd recipe:
In image (${D}) folder there is:
$ tree usr/include/
usr/include/
├── libudev.h
└── systemd
├── sd-bus.h
├── sd-bus-protocol.h
├── sd-bus-vtable.h
├── _sd-common.h
├── sd-daemon.h <======(Header file you are looking for)
├── sd-device.h
├── sd-event.h
├── sd-hwdb.h
├── sd-id128.h
├── sd-journal.h
├── sd-login.h
└── sd-messages.h
Also, libsystemd is provided by systemd package, so change DEPENDS to:
DEPENDS = "simple-web-server boost sqlite3 systemd"
# ^
# |
# ===========================================
Related
I am developing a code for my school's rocketry team and I have two programs, one meant to flash the on-board computer and another to run some data analysis on the flight data. The chip code uses no_std while the data analysis program uses std. The data-analysis code will run on my PC, and the chip code will run on the chip.
Here is my workspace root Cargo.toml and my project graph:
[workspace]
members = [
"chip",
"data-analysis",
]
.
├── Cargo.lock
├── Cargo.toml
├── chip
│ ├── Cargo.toml
│ ├── memory.x
│ ├── openocd.cfg
│ ├── openocd.gdb
│ └── src
│ └── main.rs
├── data-analysis
│ ├── Cargo.toml
│ └── src
│ └── main.rs
├── README.md
└── resources
├── 3m.mkd
├── data-stm32f103c8t6.pdf
├── links.txt
├── reference-stm32f103xx.pdf
├── schematic-stm32f103c8t6.png
└── todo.txt
I have decided to use a workspace to organize my code. When I attempt to build the workspace, I get the error:
error[E0463]: can't find crate for `std`
|
= note: the `thumbv7m-none-eabi` target may not support the standard library
= note: `std` is required by `data_analysis` because it does not declare `#![no_std]`
= help: consider building the standard library from source with `cargo build -Zbuild-std`
When I compile with cargo build -Zbuild-std I get the error:
error[E0463]: can't find crate for `panic_abort`
error[E0658]: use of unstable library feature 'restricted_std'
|
= help: add `#![feature(restricted_std)]` to the crate attributes to enable
However I need no_std and not restricted_std.
I understand that dependencies for all files are stored in Cargo.lock and presumably that's why it is producing this error. My question is, how do I express to the compiler that I need std for data_analysis but not for chip code? Should I even be using workspaces over just using one package with multiple binaries and using [features] in the Cargo.toml?
It seems like you're trying to complile data_analysis with the same target as chip. I recommend just getting rid of the root Cargo.toml and compiling the respective ones in the folders. You could make a Makefile to automate this easily
I have a barebones workspace project:
.
├── build-debug.sh
├── Cargo.lock
├── Cargo.toml
├── common
│ ├── Cargo.toml
│ └── src
│ └── lib.rs
├── rs-test.iml
├── server
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── wui
├── Cargo.toml
└── src
└── lib.rs
The rs files either empty or just an empty main function.
The server and the wui depends on common: common = { path = "../common" }.
The common project has one crates.io dependency with I suppose build script or proc macro dependency.
The build script:
cargo build -p wui --target wasm32-unknown-unknown
cargo build -p server
The problem:
When I rebuild the unchanged project, some wui dependencies are getting invalidated/rebuilt, then the same for server.
Either:
remove the wasm32 target flag
replace the dependency with a simple crate without build time compiled dependencies
It does not rebuild the subprojects anymore.
Is this a cargo bug? What can I do?
It's probably not a cargo bug. What is likely happening here is that your crates.io dependency (you don't mention what it is, which might have been useful) has different dependencies or features depending on the target architecture. Thus, as you alternate between building the WASM target and your host target, stuff is being rebuilt.
Perhaps it would be better in this case to stop using the Cargo workspace and build the server and wui separately; this way you'll have separate target directories for the server and wui, which takes some extra disk space and takes longer for non-incremental compilation, but will prevent you from having to rebuild that stuff all the time as you build both.
meta/recipes-core/initrdscripts/files/init-install-efi.sh is used for formatting and creating partitions.
I have modified this file to create one more partition for software update.
Can I copy the newly updated script file in my own custom layer recipes-core/initrdscripts/files/init-install-efi.sh.
Will it update the init-install-efi.sh. If not how to achieve this, I don't want to touch the poky source code, as that is fetched using repo utility
$ tree meta-ncr/
meta-ncr/
├── conf
│ ├── bblayers.conf
│ ├── layer.conf
│ └── machine
│ └── panther2.conf
├── recipes-core
│ └── initrdscripts
│ ├── files
│ │ └── init-install-efi.sh
│ └── initramfs-live-install-efi_1.0.bbappend
└── scripts
└── setup-environment
$ cat meta-ncr/recipes-core/initrdscripts/initramfs-live-install-efi_1.0.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI = "file://init-install-efi.sh"
After debugging, I found that it is copying the script present in the meta-intel layer and not of my layer.
This is from the output of bitbake-layers show-appends
initramfs-live-install-efi_1.0.bb:
/home/jamal/repo_test/sources/meta-intel/recipes-core/initrdscripts/initramfs-live-install-efi_%.bbappend
/home/jamal/repo_test/sources/meta-ncr/recipes-core/initrdscripts/initramfs-live-install-efi_1.0.bbappend
Can you please tell me what changes are required for my bbappend to work instead of meta-intel
Yocto provides bbappend mechanism to archive Your case without touching metadata from poky, please follow these few steps to archive this:
create new layer or use Your existing one,
in this layer create bbappend file for initramfs-module-install-efi_1.0.bb or initramfs-live-install-efi_1.0.bb (I found that this recipes are based on this script), with content:
$ cat meta-test/recipes-core/initrdscripts/initramfs-live-install-efi_1.0.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI = "file://init-install-efi.sh"
move modified script file under files directory, Your meta layer structure should look like:
$ tree meta-test/
meta-test/
├── conf
│ └── layer.conf
├── COPYING.MIT
├── README
└── recipes-core
└── initrdscripts
├── files
│ └── init-install-efi.sh
└── initramfs-live-install-efi_1.0.bbappend
4 directories, 5 files
Then finally after running do_unpack task on initramfs-live-install-efi recipe in working directory You will find Your modified file in recipe workspace,
$ bitbake -c unpack initramfs-live-install-efi
Test:
$ cat tmp/work/i586-poky-linux/initramfs-live-install-efi/1.0-r1/init-install-efi.sh
#!/bin/bash
echo "hello"
FILESEXTRAPATHS - is used to extend search path for do_fetch and do_patch tasks.
I have a Python application that comes with a setup.py script and can be installed via Pip or setuptools. However, I'm finding some annoying differences between the two methods and I want to know the correct way of distributing data-files.
import glob
import setuptools
long_description = ''
setuptools.setup(
name='creator-build',
version='0.0.3-dev',
description='Meta Build System for Ninja',
long_description=long_description,
author='Niklas Rosenstein',
author_email='rosensteinniklas#gmail.com',
url='https://github.com/creator-build/creator',
py_modules=['creator'],
packages=setuptools.find_packages('.'),
package_dir={'': '.'},
data_files=[
('creator', glob.glob('creator/builtins/*.crunit')),
],
scripts=['scripts/creator'],
classifiers=[
"Development Status :: 5 - Production/Stable",
"Programming Language :: Python",
"Intended Audience :: Developers",
"Topic :: Utilities",
"Topic :: Software Development :: Libraries",
"Topic :: Software Development :: Libraries :: Python Modules",
],
license="MIT",
)
Using Pip, the files specified in data_files end up in sys.prefix + '/creator'.
Using setuptools (that is, running setup.py directly), the files end up in lib/python3.4/site-packages/creator_build-0.0.3.dev0-py3.4.egg/creator.
Ideally, I would like the files to always end up in the same location, independent from the installation method. I would also prefer the files to be put into the module directory (the way setuptools does it), but that could lead to problems if the package is installed as a zipped Python Egg.
How can I make sure the data_files end up in the same location with both installation methods? Also, how would I know if my module was installed as a zipped Python Egg and how can I load the data files then?
I've been asking around and the general consensus including the official docs is that:
Warning data_files is deprecated. It does not work with wheels, so it should be avoided.
Instead, everyone appears to be pointing towards include_package_data instead.
There's a drawback here in that it doesn't allow for including things outside of your src root. Which means, if creator is outside creator-build, it won't include it. Even package_data will have this limitation.
The only workaround, if your data files are outside of your source files (for instance, I'm trying to include examples/*.py for a lot of reasons we don't need to discuss), you can hot-swap them in, do the setup and then remove them.
import setuptools, glob, shutil
with open("README.md", "r") as fh:
long_description = fh.read()
shutil.copytree('examples', 'archinstall/examples')
setuptools.setup(
name="archinstall",
version="2.0.3rc4",
author="Anton Hvornum",
author_email="anton#hvornum.se",
description="Arch Linux installer - guided, templates etc.",
long_description=long_description,
long_description_content_type="text/markdown",
url="https://github.com/Torxed/archinstall",
packages=setuptools.find_packages(),
classifiers=[
"Programming Language :: Python :: 3.8",
"License :: OSI Approved :: GNU General Public License v3 (GPLv3)",
"Operating System :: POSIX :: Linux",
],
python_requires='>=3.8',
package_data={'archinstall': glob.glob('examples/*.py')},
)
shutil.rmtree('archinstall/examples')
This is at best ugly, but works.
My folder structure for reference is (in the git repo):
.
├── archinstall
│ ├── __init__.py
│ ├── lib
│ │ ├── disk.py
│ │ └── exceptions.py
│ └── __main__.py
├── docs
│ ├── logo.png
├── examples
│ ├── guided.py
│ └── minimal.py
├── LICENSE
├── profiles
│ ├── applications
│ │ ├── awesome.json
│ │ ├── gnome.json
│ │ ├── kde.json
│ │ └── postgresql.json
│ ├── desktop.py
│ ├── router.json
│ ├── webserver.json
│ └── workstation.json
├── README.md
└── setup.py
And this is the only way I can see how to include for instance my profiles as well as examples without moving them outside of the root of the repository (which I'd prefer not to do, as I want users to easily find them when navigating to the repo on github).
And one final note. If you don't mind polluting the src directory, in my case that's just archinstall. You could symlink in whatever you need to include instead of copying it.
cd archinstall
ln -s ../examples ./examples
ln -s ../profiles ./profiles
That way, when setup.py or pip installs it, they'll end up in the <package dir> as it's root.
I've been really stuck on this minor (I'm sure) issue so any help would be greatly appreciated. I've created a standard ubuntu package with dh_make. The purpose of this package is to create a package that will set up all the ldap related packages that a system needs including it's configuration. One of the steps I'm trying to do is to copy over an /etc/ldap.conf file while making a backup of the existing file. How do I do this? I tried to create a postinst script that looks essentially like the following, but I'm not clear on how the package stores the files and I get an error saying missing etc/ldap.conf file. What's the best way to do this? Here is my postinst script:
#!/bin/bash -xv
install -v -b etc/ldap.conf /etc/ldap.conf > /tmp/tst 2>&1
Here is my skeleton structure:
root#hqd-clientb-16:~/navldapubuntu-0.1/debian# tree
├── changelog
├── compat
├── control
├── copyright
├── docs
├── etc
└── ldap.conf
├── install
├── postinst
├── README.Debian
├── README.source
├── rules
├── source
└── format
├── navldapubuntu
└── etc
├── navldapubuntu.debhelper.log
├── navldapubuntu.dirs
└── navldapubuntu.doc-base.EX
Here's some additional information of the package I created.
dpkg --contents tnoldapubuntu_0.1-1_all.deb (truncated output)
./usr/
./usr/share/
./usr/share/doc
./usr/share/doc/navldapubuntu/
./usr/share/doc/navldapubuntu/copyright
./usr/share/doc/navldapubuntu/README.Debian
./usr/share/doc/navldapubuntu/changelog.Debian.gz
./etc/ldap.conf
There is a special tool that designed for creation of configuration packages: http://debathena.mit.edu/config-packages
Here is a simple template that could be helpful for a quick start.
List of files
template (directory)
template/debian (directory)
template/debian/control
template/debian/changelog
template/debian/displace
template/debian/rules
template/debian/postinst
template/debian/install
template/debian/docs
template/debian/compat
template/README
template/BUILD
template/files (directory)
template/files/etc/ldap.conf.mycompanyname
Content
template/debian/control:
Source: PACKAGE_NAME
Section: morpho/misc
Priority: optional
Maintainer: MAINTAINER
Build-Depends: debhelper, config-package-dev (>= 5.0~)
Package: PACKAGE_NAME
Architecture: all
Depends: ${misc:Depends}, DEPENDENCY [, DEPENDENCY ...]
Provides: ${diverted-files}
Conflicts: ${diverted-files}
Description: PACKAGE_DESCRIPTION_SHORT
PACKAGE_DESCRIPTION_LONG.
template/debian/displace
/etc/ldap/ldap.conf.mycompanyname
template/debian/install
files/* /
template/debian/postinst
#!/bin/sh
set -e
#DEBHELPER#
POSTINST_SCRIPT
template/debian/rules
#!/usr/bin/make -f
# Exclude *.svn* from building
# you probably don't need this if don't use SVN
export DH_ALWAYS_EXCLUDE=.svn
# Core (check http://debathena.mit.edu/config-packages for more information)
%:
dh $# --with=config-package
# Prevent dh_installdeb of treating files in /etc as configuration files
# you need this if need configuration files been always rewritten
# even if changed
override_dh_installdeb:
dh_installdeb
rm debian/*/DEBIAN/conffiles
template/debian/docs
README
BUILD
And finally you can build this package with the following command:
dpkg-buildpackage -us -uc -I.svn
You need to create a "conffiles" file in the DEBIAN directory, next to the "control" file, and declare /etc/ldap.conf in it. So this file will be automatically considered a configuration file, and changes to it will prompt a "new config file, would you want to overwrite, yadda yadda".