I am making an operating system with Yocto. I created new meta, new layer, new recipe and new machine. It was working fine until I tried to include packages already compiled for debian. Normally, I was installing these packages with the apt-get command after flashing the image, but as the number of packages increased, they started to conflict with the packages that came with the image and compiled with bitbake, so I am trying to add these packages as a recipe.
Can I create recipe directly from .deb file or .dsc file? If I can't create it, how can I find the source code and how can I create a recipe from the source code?
I'm currently using the OpenEmbedded dunfell version, but I'm planning to switch to the kirkstone version. Since I'm using dunfell version, I'm looking at debian's stretch version packages. Which version packages of debian should I look for when I switch to kirkstone version?
I am compiling for armhf architecture on Intel 64 bit Ubuntu 18.04. I'm compiling for a custom board.
These are the packages I'm trying to install for now (I think I can install similar packages if I can install them with a recipe):
xbindkeys
libcrypto++6
libcurl3-gnutls
default-jre-headless
libccid
libpam-pkcs11
pcscd
libacsccid1 (This is special because it only has deb package. There is no source code or dsc file.)
Whilst Yocto Project and OpenEmbedded can output deb packages they are only compatible with the DISTRO setting that built them in OE. Packages from Debian are not compatible.
You can look at https://layers.yoctoproject.org/ to search for recipes in other layers which may be able to build what you need once those layers are added.
Where you can't build from source you may be able to extract files from a Debian deb and turn it into a different deb that might work with OE but it assumes the binaries are compatible and they may or may not be depending on how you've configured your build. This isn't recommended.
Related
I got a binary kernel module provided by 3rd party, which expects version magic 5.4.0-81-generic SMP mod_unload modversions aarch64 of the kernel. It means that I need to grab the exact source tree to build the kernel for using the .ko, on my own customized SoC platform.
Now I have serveral questions for this task:
5.4.0-81-generic: 5.4.0 seems refer to the official kernel version 5.4; what is 81? Is this a patch level (or abi number)?
Can I obtain the exact source tree by patching the official kernel version 5.4? If so, where can I find the corresponding patch file for patch level 81?
I can do apt install linux-source-5.4.0, but there is no patch level on the linux-source pkg name. However, to install the headers, there are patch level on the pkg name, e.g. apt install linux-header-5.4.0-81? Why the difference?
Thanks!
Ubuntu collects its own patched sources into a source package which you can download.
The version number includes a build version; the upstream sources (the Linux kernel) does not have an Ubuntu build, but each released build has a specific version with a number after the dash and you want exactly the right one.
apt-get install linux-headers-$(uname -r)
If you want the full sources,
apt source linux-generic
though in practice you want to read the instruction it prints and download the sources from Github.
Perhaps see also https://ubuntu.com/kernel and https://linuxhint.com/install-linux-kernel-ubuntu/
I am trying to install SDL2 on Linux Ubuntu 18.04. However there are 2 types of packages available on the repository, the 'normal' library version and the development files version.
libsdl2-2.0-0/bionic-updates,bionic-security 2.0.8+dfsg1-1ubuntu1.18.04.4 amd64
Simple DirectMedia Layer
libsdl2-dev/bionic-updates,bionic-security 2.0.8+dfsg1-1ubuntu1.18.04.4 amd64
Simple DirectMedia Layer development files
What I am asking is are there differences between the two version for developing application/game using SDL2 and which one should I install if I am just starting to learn SDL2?
Ubuntu (and other Linux distributions) often divide up packages this way: the first package contains libraries and executables needed to run something compiled with the package (SDL2 in this case), the dev packages contains the headers, additional libraries or config files needed to compile a program with package. You want to install both; normally installing the dev version of the package will pull in the other as a dependency.
You will need both, most likely :)
The lib package contains the binary SDL library. That's needed to run a program.
But in order to develop an application, you need the C header files to include in your source code - assuming that you want to create a program in C or C++. The compiler needs these files to 'see' the functions provided by the lib.
If you want to use SDL library in a different way, you could also use python and python-pygame-sdl2.
I have been working with Linux kernel, compiling and inserting modules, in my custom kernels. Previously I had Ubuntu where I had been working with my custom kernel and all the commands for compiling and installing kernel worked like a charm once I had installed all the required libraries.
Now I have switched over to Fedora 20, here I want to install my custom kernel and for that I downloaded all possible kernel tools, namely, Kernel Development Kernel Tools these are group installs and other libraries that I downloaded were ia32 libraries (as I am working on 64-bit OS), kernel-devel package. Still I am not able to work with make-kpkg command. It says bash: make-kpkg: command not found....
I googled out and did everything I could.
Can anyone get me out of this trouble?
make-kpkg is a Debian kernel packaging tool. It does not exist on RHEL family distributions, such as Fedora.
Please refer to the Fedora documentation page "Building a custom kernel" for the correct procedure. (I have not reproduced it here as it is rather long, and I'm not sure how far you may have gotten.)
The make-kpkg tool is part of the 'kernel-package' package on Debian systems. It is a Debian tool to produce debian package files. Ubuntu is based on Debian and has this tool. However, Fedora uses a different system to manage packages. So, make-kpkg would not be available on Fedora.
I have a project that runs on Debian and uses many packages provided from the Debian repositories.
Because of demand, I've looked into porting the project to CentOS, but found that many of the packages I require are completely missing - at least 10 dependencies would have to be compiled manually at install time on the users machine.
My question is, what is the best way to create an installer for the user's machine? Should I use automake tools (with the standard ./configure, make, make install), to compile the required libraries, or is this a non-standard approach. Note that my app doesn't actually need to be compiled since it is written in Python, so is it weird to do a "make", when you're not compiling your own app?
Should the configure script just warn the user that package X is missing, and let them handle the rest?
Should I roll my own dependency checker by runng pkg-config manually a few times for each library required, and exit if something is missing?
I'm quite new to this, so any tips to get me moving in the right direction are appreciated.
Edit: I am familiar with RPM and yum for red hat base distros, but CentOS is missing many multimedia packages that I require. An example of one of my package dependencies is "liquidsoap" which is a programmable audio engine: http://savonet.sourceforge.net/
This is available on Debian, but not Redhat/Centos
See this link on CentOS package management.
http://wiki.centos.org/PackageManagement/Yum
CentOS is redhat based and does not use .deb packages by default. However apt package management has been ported to tons of platforms, you may be able to use a port for centOS
If you use YUM whatever packages you need will be there for your application as redhat distros need all the same things that any other distro does.
EDIT: To get the details out of comments
Packages not available on the target platform either have to be built (possibly as a port) on the target platform and then shipped in the ported package (in this case YUM), or code needs to be modified and forked to use packages which already are available on the target platform. The choice depends on which is worse, or which is even possible given your constraints.
I have Qt 4.6.3 on Debian. I need version 4.8.1.
To install it I downloaded the Qt SDK 1.2.1 from the Qt site, where is said that it contains version 4.8.1
After installation I checked Qt version and it is 4.6.3 instead of expected 4.8.1.
What I am doing wrong? And how can I install 4.8.1?
First of all I recommend getting 'official' Debian Qt upgrades by adding the testing (wheezy) repo to your package manager, this way everything on your system will be updated seamlessly in a few clicks.
If you can't do this, then:
Use your package manager to uninstall the existing Qt installation (so that's the runtime libs, plugins, and Qt Creator).
Install the SDK anywhere you like, it installs under one folder anyway.
Update your $PATH to point to the directory with qtcreator, qmake, etc., there are numerous ways of doing this, the simplest is exporting the updated $PATH in your .bashrc. (And optionally make some nice shortcuts for your DE).
Create symlinks in /usr/lib (or /usr/lib64) to point to the Qt libraries the SDK provides, or add a qt.conf file containing the path in your /etc/ld.conf.so.d/ directory and run ldconfig as root.
I'm an openSUSE user myself, so some of the above may slightly different on Debian, hopefully someone with Debian experience can chime in if I'm incorrect.