I have a relatively simple receipt file (stripped version of the ntp) with no installation of the {bindir}. However, unless I explicitly remove the {bindir} in the do_install_append I get a QA error saying:
ERROR: ntp-4.2.8p9-r0 do_package: QA Issue: ntp: Files/directories were installed but not shipped in any package:
/usr/bin
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
ntp: 1 installed and not shipped files. [installed-vs-shipped]
ERROR: ntp-4.2.8p9-r0 do_package: Fatal QA errors found, failing task.
Why is the removal needed in this recipe? Is there some other recipe that is installing {bindir}?
There is some default do_install provided by https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/base.bbclass. If you only want to install what you want. Please overwrite do_install () instead of do_install_append (). Otherwise you need to add all files FILES_${PN}.
Related
I'm relativly new to the whole Yocto Project.
Basically I want to add multiple folders to the image:
do_install() {
install -d ${D}/etc/wpa_supplicant
install -m 0777 wpa_supplicant-wired-eth0.conf ${D}/etc/wpa_supplicant
install -d ${D}/mydata
install -d ${D}/mydata/certs
}
wpa_supplicant needs a conf file in /etc/wpa_supplicant. So I install the folder and copy my custom conf file there.
This works FINE
Simultaneously I want to install a certificate folder under /mydata/certs where I can later upload my certificates for the wpa_supplicant.
But when I do do that Yocto tells me the old install vs shipped error
mywpa-1.0-r0 do_package: QA Issue: mywpa: Files/directories were installed but not shipped in any package:
/mydata
/mydata/certs
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
mywpa: 2 installed and not shipped files. [installed-vs-shipped]
ERROR: mywpa-1.0-r0 do_package: Fatal QA errors found, failing task.
ERROR: mywpa-1.0-r0 do_package: Function failed: do_package
ERROR: Logfile of failure stored in: /home/yocto/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-phytec-linux-gnueabi/mywpa/1.0-r0/temp/log.do_package.31833
ERROR: Task (/home/yocto/yocto/sources/poky/../meta-mydata/meta-mywpa/recipes-mywpa/mywpa/mywpa.bb:do_package) failed with exit code '1'
Previously I just worked I had ONE folder per recipe and just added
FILES_${PN} += "${sysconfdir}/etc"
So my question is basically: How do I install two folders in two different directories? Or is impossible in a single recipe and I have to use two recipes?
The FILES_${PN} += expression can be almost arbitrarily complex, as long as it is static at parse time. So you should be able to just expand it as needed:
FILES_${PN} += " \
${sysconfdir}/etc/wpa_supplicant \
/mydata \
"
If there's any problems with that approach, please update the question then I can look into it.
I'm trying to build my extension using Powershell for my Build/Release tasks for Azure DevOps. When I upload and install my extension, I keep getting the following error:
##[error]File not found: 'E:\ADOAgents\Agent1\_work\_tasks\MDDSVisualStudioBuild_c2ba1f80-29d5-11e7-b903-6faaecee54d3\1.0.2\ps_modules\VstsTaskSdk\VstsTaskSdk.psd1'
I used the following instructions on how to build my tasks from this tutorial. I have also used the following question from StackOverflow to make sure I didn't get this error but I was never able to solve it.
Here is the file structure of my tasks:
package-lock.json
README.cmd
vss-extension.json
MDDSVisualStudioBuild
-task.json
-icon.png
-task.loc.json
-VSBuild.ps1
-ps_modules
-VstsTaskSdk
-* (all the files)
This is how I build my extension:
1. use node 10.16
2. npm install
3. npm init -y
4. npm install -g azure-pipelines-task-lib --save
5. npm i -g tfx-cli
6. tfx extension create --manifest-globs vss-extension.json --rev-version
7. Copy *vsix Files to: $(Build.ArtifactStagingDirectory)
8. Publish vsix Artifact: package
I really don't understand what I'm doing wrong here...
I figured it out. The version in my vss-extension.json wasn't matched with the version in my task.json.
:( This took me forever
After cloning the project code from the Repository, I'm trying to install the npm to update the packages and plugins included. The command used is:
npm install
It worked well for previous clones. But now it displays the following error:
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsevents#1.0.12
npm WARN appname# No repository field.
npm WARN appname# No license field.
When I tried to install fsevents using --verbose, it is said that the supported OS is Darwin. But it worked in the previous clone. Why not now?
If your a Windows user:
The fsevents warning isn't a problem. It's an optional dependency and isn't needed for this to work on Windows.
But the error still displaying, in order to fix this.
Open package.json and delete the gulp-watch dependecy
Manualy remove the folder (gulp-watch) from the node_modules fordel
Unload the Project and uploaded again
The error is gone!!!
There's a issue open to fix this in .net core , but this will work untill then.
I've got several versions of some package. The last of it has an error in %pre section that terminates the install script:
mypak-0.0.1-1.el6.noarch.rpm
mypak-0.0.1-2.el6.noarch.rpm
mypak-0.0.1-3.el6.noarch.rpm <-- bad package
All of my packages have debug output in pre, post, preun and postun sections.
I install the first package:
rpm -Uhv mypak-0.0.1-1.el6.noarch.rpm
Output (param is the parameter passed to script sections) is:
Preparing... ########################################### [100%]
pre: 0.0.1-1.el6 ; param = 1
1:mypak ########################################### [100%]
post: 0.0.1-1.el6 ; param = 1
Then I try to update my package and (accidentally) launch rpm command with all the packages at once:
rpm -Uhv mypak-0.0.1-*
warning: package mypak = 0.0.1-1.el6 was already added, replacing with mypak > 0.0.1-2.el6
warning: package mypak = 0.0.1-2.el6 was already added, replacing with mypak > 0.0.1-3.el6
Preparing... ########################################### [100%]
pre: 0.0.1-3.el6 ; param = 2
!!!version 3 is bad!!!
error: %pre(mypak-0.0.1-3.el6.noarch) scriptlet failed, exit status 1
error: install: %pre scriptlet failed (2), skipping mypak-0.0.1-3.el6
preun: 0.0.1-1.el6 ; param = 0
postun: 0.0.1-1.el6 ; param = 0
As you can see, my package was removed in the end. Moreover, the package is removed even if other packages depend on it. I don't even get any warnings about corrupted dependencies!
If I install my packages one after another, I don't have that problem. In this case installation of the third package fails and that's all. The previous version of my package is still in place.
I think this is really a strange behaviour. Is it a bug in rpm or am I missing something?
I use rpm 4.8.0 on Centos 6.5.
RPM will ignore (by substituting newer version) older versions of identically named packages when installing. Either rename some of the packages, or don't install multiple versions of an identically named package in the same transactio
%pre failures when upgrading are tricky. The newer package will not install if %pre fails. and (on upgrade when there is an older version already installed) will remove the already installed package. The best answer here is don't rely on %pre failures in packaging while installing. Instead add Provides:/Requires:
so that the package (and transaction) failure occurs during dependency checking, or design a different means for testing a dynamic property than %pre,
either in configuration, or in documentation, or by renaming and obsoleteing the previous package to get a more reliable packaging.
I wrote about this behaviour to the RPM mailing list and Lubos Kardos answered that this is a bug and now it is fixed.
Mailing list thread: http://lists.rpm.org/pipermail/rpm-list/2015-April/001740.html
Commit: https://github.com/rpm-software-management/rpm/commit/c7fa7b2fd7205b73c833831ab9f8c311f40b2ff1
I have a really strange issue with the behavior of pip in a virtualenv.
I have set
export PIP_REQUIRE_VIRTUALENV=true
export PIP_DOWNLOAD_CACHE=$HOME/.pip/cache
export VIRTUALENV_DISTRIBUTE=true
Now, when I'm in my virtualenv and want to install my dependencies:
pip install -r requirements/_base.txt
(for testing purposes, requirements/_base.txt only contains:)
Django==1.5
Anyway, when I try to install it, I only get:
Downloading/unpacking Django==1.5 (from -r requirements/_base.txt (line 1))
Running setup.py egg_info for package Django
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
And after that, Django is not installed.
Here comes the strange part: When I install Django manually with
pip install Django==1.5
it's working perfectly (though the same two warnings appear):
Downloading/unpacking Django==1.5
Running setup.py egg_info for package Django
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
Installing collected packages: Django
Running setup.py install for Django
changing mode of build/scripts-2.7/django-admin.py from 644 to 755
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
changing mode of /usr/local/share/python/django-admin.py to 755
Successfully installed Django
Cleaning up...
I faced a similar problem and realized that removing the version requirement solved the problem. Don't know why though...
I figured out why this was happening to me, which may also solve the problem for others who see this page. For me, the problem was that I had a requirement that can not install automatically via pip. The pip freeze exported the package name and version but, for whatever reason, pip cannot install that package directly in a requirements install. I have to instead install it manually from a zip file.
The problem you might be experiencing, then, is that you have a requirement which cannot be installed by pip's requirements installer. Check your output log for red text, errors, that sort of thing.
I figured this out using this post:
pip fails to install packages from requirements.txt