I want to create a yum repository from my Artifactory URL where I have various rpm packages available.
I created .repo file as below in /etc/yum.repos.d
[customrepo]
name=CustomRepository
baseurl=https://jfrogurl/postgres/13.01.0000
enabled=1
gpgcheck=0
After this when I type yum list I get the following error:
Error: Failed to download metadata for repo 'customrepo': repomd.xml parser error: Parse error at line: 32 (Opening and ending tag mismatch: meta line 0 and head)
Am I missing anything?
You need to make sure that the baseurl in yum.repos.d points to the path which contains the Yum repository metadata files.
From your question it looks like you are pointing to postgres/13.01.0000. You need to make sure that this path contains the metadata files.
By default the metadata is stored relative to the repository's root folder. In this case, Artifactory searches the entire repository for RPMs and saves the repodata directory at $REPO-KEY/repodata. You can control this behavior by configuring the RPM Metadata Folder Depth parameter.
Related
I am currently so confused about installation of my own Python packages... Between setup.pys, sdists and wheels, no matter what I do, I can't seem to achieve what I want - which is to have a bunch of non-.py data files installed and kept in the virtual environment with the same structure I have in my project folder after the installation.
I've read all kinds of documentations, and created a setup.py file that has a data_files field that contains all the data files I need in my installation.
I have the following structure:
.
|__ requirements.txt
setup.py
hr_datapool
|__ __init__.py
|__ data_needed
|__ needed_folder
|__ needed_file.notpy
|__ one_module
|__ __init__.py
|__ misc_tools.py
|__tests
|__ test_tools.py
|__ other_module
...
And data_needed contains non-.py data files that are needed for misc_tools.py (and thus tests.py) to run.
Because of this, I added a data_files into my setup.py that contains all the folders and files I need. This I confirmed, everything is there what should be.
And yet, if I do any variation of pip install ., python setup.py install or the likes, the data_files are completely ignored, and/or placed in the wrong directory and don't appear anywhere in the created build or dist folders. And because of this, obviously all my tests fail, since they can't load files that are not there. Neither are they stored in the installation folder on the venv when I sometimes do succeed in copying them, but rather in the root of the venv.
The funny thing is, the files are handled while installing, I keep getting console output when installing with python setup.py install like:
copying data_needed/needed_folder/needed_file.notpy-> /Users/.../venv/hr_datapool/data_needed/needed_folder/
but only if I use python setup.py install, (not when using pip install .).
According to the documentation:
The directory should be a relative path. It is interpreted relative to the installation prefix (Python’s sys.prefix for system
installations; site.USER_BASE for user installations). Distutils
allows directory to be an absolute installation path, but this is
discouraged since it is incompatible with the wheel packaging format.
No directory information from files is used to determine the final
location of the installed file; only the name of the file is used.
Notice the highlights. However, in my example, it doesn't install relative to the directory containing the package, but it installs into its own folder in the root of the virtual environment, making it practically unreachable from within my code. I made sure I se relative paths in my setup.py, but still this happens.
How can I make sure the required data_files install within the target directory of the module, and not separately into the root of the virtual environment?
I new to Yocto so there are probably some mistakes and misunderstanding that I've had, I appreciate if you can help.
So, I want to add a new package (tar file) to my custom image.
I have followed steps and steps in manual and some online instructions. While running: "bitbake mylayer", the layer is built fine but I got this error while building the image, here is the log file:
DEBUG: Executing python function rootfs_deb_bad_recommendations
DEBUG: Python function rootfs_deb_bad_recommendations finished
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Installed into sysroot: []
NOTE: Skipping as already exists in sysroot: ['depmodwrapper-cross', 'apt-native', 'dpkg-native', 'pseudo-native', 'update-rc.d-native', 'prelink-native', 'makedevs-native', 'ldconfig-native', 'opkg-util$
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing python function do_rootfs
NOTE: ###### Generate rootfs #######
NOTE: Installing the following packages: apt busybox copy-uefiimg-to-sda coreutils dpkg e2fsprogs-resize2fs libfontconfig1 libfreetype6 libglib-2.0-0 gptfdisk libjemalloc2 kernel-module-axi-dma-sensor ku$
ERROR: Unable to install packages.
Reading package lists...
Building dependency tree...
Reading state information...
Package mypackage is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'mylayer' has no installation candidate
DEBUG: Python function do_rootfs finished
ERROR: Function failed: do_rootfs
And here is mylayer.bb:
SUMMARY = ""
LICENSE = "CLOSE"
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://mypackage.tar"
Also, I have included the package in conf/local.conf:
IMAGE_INSTALL_append += " mylayer"
So beside trying to figure out how to solve this problem, I also have some questions:
I have read some example of .bb, and they mentioned about LIC_FILES_CHKSUM. The mypackage.tar.gz is a package to install a platform for the device and I don't know much about the source code, so I don't know if it is necessary to include the license? Or how to know that this package need license to install?
In some answer I found online, there is one saying that I need to include PACKAGE_CLASSES ?= "package_deb" (they want to install the .deb file), so probably in my case I will need PACKAGE_CLASSES ?= "package.tar" right? I have tried to change variable, but it still not successful.
The mypackage.tar includes some deb files. If I could not install mypackage.tar, can I instead install these .deb files? Can I put it all in mylayer.bb?
Thank you in advanced, I have tried to study much documents as I could but I get so confused and there is huge amount of information to digest.
First, before answering your questions
Let me mention some best practices advice for you:
Rename the recipe to some significant name related to you compressed package.
Naming the recipe to mylayer confuses Yocto users, because there is the term layer also.
Regarding you recipe:
There is no need for FILESEXTRAPATHS because the recipe path is added automatically to Yocto paths.
FILESEXTRAPATHS it is required for .bbappend files.
You need to override the do_install task function, it does nothing by default.
do_install is the first essential task to make sure that your sources are included in the final image.
Beside that, when specifying a compressed source file into SRC_URI, yocto automatically decompresses it.
This is mentioned here.
So, here what your recipe should look like:
SUMMARY = ""
LICENSE = "CLOSED"
# Prevent Yocto from decompressing the file
SRC_URI = "file://mypackage.tar;unpack=0"
do_install(){
# Create the opt folder into the final image, ${D} is ${WORKDIR}/image
install -d ${D}/opt
# Copy the compressed file there; You can change permissions as you want
install -m 0755 ${WORKDIR}/mypackage.tar ${D}/opt
}
# Very important to specify what you installed in (do_install)
FILES_${PN} = "/opt/*"
Now, when you run IMAGE_INSTALL_append += " mylayer" your file will be installed.
Regarding your questions:
You mentioned that your compressed file contains .deb files, I assume that no license checksum is needed. Also, I understand that you may wanted to point to SRC_URI[md5sum] or other checksums for the full package. That is also not needed for local files, it is used to check for the integrity of online sources.
PACKAGE_CLASSES as mentioned here, is used by the system to know in what type the data should be packaged. By the data I mean the data that you installed with do_install. That data get packaged for according to your PACKAGE_CLASSES variable, for example, to deb file. And that is used, along side with all other recipes packages, to build the final rootfs.
Yes, if you are installing the tar file into the image and then unpack it to install all deb files, for example, with dpkg. You can use the bin_package class to do that, now the recipe must be changed for that reason:
Decompress the tar file and provide the deb files in the local files folder.
Add all deb files to SRC_URI
Inherit the bin_package class
Specify the files to be packaged.
Your recipe should look like this:
SUMMARY = ""
LICENSE = "CLOSED"
SRC_URI = "file://deb_file1.deb \
file://deb_file2.deb"
# No need to `do_install` , it is invoked by the (bin_package) class
FILES_${PN} = ""
Important:
About FILES_${PN}, you need to add all what the deb installed into the image folder
Example, if your deb file installs this:
/usr/bin/hello
/etc/hello.cfg
Specify them:
FILES_${PN} = "/usr/bin/*"
FILES_${PN} += "/etc/*"
Use * so if other deb files install files into the same folder as others it will include all.
I want to add gedit to the the image. But i am not able to find the dependencies of gedit package. How to find the dependencies (DEPENDS) in yocto.
You can use the following command which opens up a Dependency explorer that displays dependencies on the packages:
bitbake -g recipe-name -u depexp
or bitbake -g gedit -u depexp, in your case.
On pyro and later use:
bitbake -g recipe-name -u taskexp
Note: this command needs python-gtk2 installed.
You can also use Toaster, which is a web UI that collects information about what you build, including dependencies. This video shows the dependency information provided:
https://www.youtube.com/watch?v=x-6dx4huNnw
Details on how to set up and use Toaster at
https://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html
The list of packages installed in your image is stored in the manifest file (besides of build history which is already mentioned).
Content of the manifest file looks like:
alsa-conf cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-conf-base cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-lib cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-states cortexa7hf-neon-vfpv4 0.2.0-r5.1
alsa-utils-alsactl cortexa7hf-neon-vfpv4 1.1.2-r0.5
alsa-utils-alsamixer cortexa7hf-neon-vfpv4 1.1.2-r0.5
...
The list consists of the package name, architecture and a version.
That manifest is located in the deploy directory (i.e. deploy/images/${MACHINE}/). Here as an example of the directory listing (there are target images and the manifest file)
example-image-genericx86.ext3
example-image-genericx86.manifest
example-image-genericx86.tar.bz2
How do I install Helm (https://hackage.haskell.org/package/helm) on Windows 7 (64-bit)?
(Update: I had posted a lot of error messages here, but I've moved them to my answer to not clutter up the question.)
Installation for Windows 64-bit:
I'm including error messages, for if you follow all the steps up to that point and then just try to install directly. This is a conglomeration of a bunch of ad-hoc steps from following many different posts. Any simplification would be appreciated!
Note: Do all work in directories without spaces. I'm doing all work in C:/PF; modify this to your directory.
Download MSYS2-x86_64 from https://msys2.github.io/ and install it. Cabal install cairo (or helm) will give something like:
Configuring cairo-0.13.1.0...
setup.exe: Missing dependencies on foreign libraries:
Missing C libraries: z, cairo, z, gobject-2.0, ffi, pixman-1, fontconfig,
expat, freetype, iconv, expat, freetype, z, bz2, harfbuzz, glib-2.0, intl,
ws2_32, ole32, winmm, shlwapi, intl, png16, z
Download C libraries. In MINGW64 (NOT MSYS2 - I had trouble with MSYS2 at random stages in the process), use the package manager:
pacman -Ss cairo
to search for the Cairo package. You'll find "mingw64/mingw-w64-x86_64-cairo", so install that:
pacman -S mingw64/mingw-w64-x86_64-cairo
*.pc files should have been added to C:\PF\msys64\mingw64\lib\pkgconfig and C:\PF\msys64\usr\lib\pkgconfig. (pkg-config needs to be able to find these files. It looks in PKG_CONFIG_PATH, which by default should have the lib/pkgconfig folder above. Moving the file here is easiest. See Can't install sdl2 via cabal) If you get
The pkg-config package ... version ... cannot be found
errors then check your *.pc files.
Repeat with other required libraries, like atk
pacman -S mingw64/mingw-w64-x86_64-atk
(I don't know the complete list, but error messages later on will let you know what to get.)
Get the development files for these libraries (as suggested by How to install cairo on Windows). Most of them are bundled up at http://ftp.gnome.org/pub/gnome/binaries/win64/gtk+/2.22/. Unzip.
Copy files (.a, .dll.a) in lib to C:\PF\msys64\mingw64\lib. Copy the pkgconfig folder, which contains the .pc files.
Copy files in include to C:\PF\msys64\mingw64\include.
Add C:\PF\gtk+-2.22.1\bin to the path.
(2) and (3) might be redundant. I don't know - I did them both.
At this point you can probably do "cabal install cairo". (Warning: if your end goal is something else, you may not want to "cabal install" intermediate packages, see https://wiki.haskell.org/Cabal/Survival#Issue_.232_--_Not_installing_all_the_packages_in_one_go.)
See (4) for the syntax in specifying extra-include-dirs and extra-lib-dirs (but if you copied the files above this shouldn't be necessary),
Any time you get
Missing (or bad) header file
check to see you copied the *.h files to mingw64\include and/or add the include folder to the PATH. Use cabal install -v3 to get verbose error messages if the problem persists.
If you get something like
cairo-0.13.1.0: include-dirs: /mingw64/include/freetype2 is a relative path
which makes no sense (as there is nothing for it to be relative to). You can
make paths relative to the package database itself by using ${pkgroot}. (use
--force to override)
try --ghc-pkg-options="--force" (as mentioned at https://github.com/gtk2hs/gtk2hs/issues/139).
Get SDL. Otherwise you'll get
configure: error: *** SDL not found! Get SDL from www.libsdl.org.
If you already installed it, check it's in the path. If problem remains,
please send a mail to the address that appears in ./configure --version
indicating your platform, the version of configure script and the problem.
Failed to install SDL-0.6.5.1
Follow the instructions in (2) to get sdl/sdl2 libraries. (See instructions here Installing SDL on Windows for Haskell (GHC).)
The new version helm-0.7.1 requires sdl2, but there are other dependency issues with helm-0.7.1 as of writing. Download SDL from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/ (direct download link to newest version as of writing http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/mingw-w64-x86_64-SDL-1.2.15-7-any.pkg.tar.xz.sig/download), unzip. "cabal install sdl" gives
* Missing (or bad) header file: SDL/SDL.h
* Missing C library: SDL
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
so we specify where the dirs are (change the name depending on where you extracted sdl to)
cabal install sdl --extra-include-dirs=C:/PF/sdl\include --extra-lib-dirs=C:/sdl/lib
If you got SDL2 (http://libsdl.org/download-2.0.php) (for a newer version of Helm): there is a fatal bug that hasn't been fixed in the release version. (If you don't fix it, cabal install -v3 things which depends on it will give error
winapifamily.h: No such file or directory
("winapifamily.h: No such file or directory" when compiling SDL in Code::Blocks) Download https://hg.libsdl.org/SDL/raw-file/e217ed463f25/include/SDL_platform.h, replace the file in the include folder and in C:/PF/msys64/mingw64/include/SDL2.
Download gtk2hs from http://code.haskell.org/gtk2hs and run
the following
cd gtk2hs/tools
cabal install
cd ../glib
cabal install
cd ../gio
cabal install
cd ../pango
cabal install --ghc-pkg-options="--force"
(Maybe you have already installed glib and gio from before? I did this step because normal install of Pango caused an error for me (https://github.com/gtk2hs/gtk2hs/issues/110)
pango-0.13.1.0: include-dirs: /mingw64/include/freetype2 is a relative path
which makes no sense (as there is nothing for it to be relative to). You can
make paths relative to the package database itself by using ${pkgroot}. (use
--force to override)
Once the Helm developers get things updated you should be able to do "cabal install helm" but right now there seem to be dependency issues. For me, cabal automatically tries to install helm-0.4 (probably because 0.4 didn't give upper bounds on dependencies, while newer versions do. You could try "cabal unpack"ing and deleting the upper bounds...). Then
cabal unpack helm-0.4
Installing gives an error because "pure" got moved to Prelude. Open helm-0.4\src\FRP\Helm\Automaton.hs and change line 17:
import Prelude hiding (id, (.), pure)
Now
cabal install
Try to compile and run a program using Helm
(This is 0.4 - look on the website for a newer sample if you tried a newer Helm)
import FRP.Helm
import qualified FRP.Helm.Window as Window
render :: (Int, Int) -> Element
render (w, h) = collage w h [filled red $ rect (fromIntegral w) (fromIntegral h)]
main :: IO ()
main = run $ fmap (fmap render) Window.dimensions
If you get an error about a missing .dll (sdl.dll), find it in a bin/ folder and add the folder to your PATH (or copy it to somewhere on your path).
I have created rpm with following name:
[root#buildbtl ship-rpms]# ls
cdd-pcts-5.1.1.el6.x86_64.rpm
I installed rpm with the command
rpm -ivh cdd-pcts-5.1.1.el6.x86_64.rpm
After querying the installed package the name gets changed to
cdd-pcts-5.1.1-.el6.x86_64
[root#buildbtl ship-rpms]# rpm -qa | grep cdd-p
cdd-pcts-5.1.1-.el6.x86_64
I cannot understand why extra - is added after version 5.1.1
How can I maintain the name of the created rpm and installed rpm as same.
In the spec file I have overridden the MACRO _build_name_fmt for naming the rpm
using the command below:
%define _build_name_fmt %{NAME}-%{_VERSION}%{Release}.%{ARCH}.rpm
Thanks in advance for guidance
It doesn't matter how would you rename rpm package file (in your case via changing definition of _build_name_fmt), it's actual package name (which rpm database actually cares about) is always stored inside the package along other rpm metadata. This means that the easiest way to ensure that name of rpm package is the same both in rpm database and in rpm build filename is to not change the _build_name_fmt.
The RPM database always stores four "metadata" fields which identify the package: name, version, release and arch (architecture). It gets this information by reading the contents of the RPM file; its filename is irrelevant. There are additional metadata fields for RPMs which you can see using the rpm -qipackage command (see The Parts of an RPM Query for more information).
In your example, it appears that
name is "cdd-pcts",
version is "5.1.1",
release is ".el6', and
arch is "x86_64"
The default format for displaying this information is name-version-release.arch, which puts a "-" immediately before the release ".el6". Perhaps %{Release} is built up from two symbols, and in modifying the spec-file you made one of those symbols empty.
Before installing, you can also inspect your package to check if the metadata is set correctly, e.g.,
rpm -qip cdd-pcts-5.1.1.el6.x86_64.rpm