My current linux system has kernel-3.10.0-693.21.1.el7.x86_64 installed and now am trying to upgrade it to kernel-5.5.7 which is the latest stable release.
Post compiling the tarball for kernel-5.7.7 obtained from https://www.kernel.org/ I obtained an rpm which is close to 590M in size. The previous rpm that my existing machine uses is mere 150M.
I used https://linuxhint.com/compile-linux-kernel-centos7/ for compilation.
On observing file content, I see all files in the 3.10.0.693 rpm are compressed with .xz extension whereas this compression was not present in my newly compiled rpm.
I tried a CONFIG_MODULE_COMPRESS_XZ=y and CONFIG_DECOMPRESS_XZ=n options before starting make binrpm-pkg but yet the rpm size is huge.
Can anyone suggest what flags to use and where to use them? Shall I edit the .config file or the Makefile for each file within the rpm to be compressed with .xz extension.
Following is just for reference
rpm -ql kernel-3.10.0-693.21.1.el7.x86_64 | grep '.xz' | wc -l
2406
rpm -qpl kernel-5.7.7-1.x86_64.rpm | grep '.xz' | wc -l
0
I figured out by default the DEBUG KERNEL is enabled in the kernel tarball.
Generated the config using make menuconfig and edited the .config file and changed CONFIG_DEBUG_KERNEL=y to CONFIG_DEBUG_KERNEL=n and executed make binrpm-pkg.
The rpm generated was of 57MB which is very much acceptable.
Related
I am downloading packages using repotrack, doing something like this -
repotrack -a x86_64 -p $PACKAGE_LOCATION/Packages $pckg
where it gets $pckg from a text file. Now I want to verify signatures of all packages (and dependencies) before installing.
rpm --checksig <package_name>
Here I need package_name of all packages and dependencies downloaded. One way to do this will be ls over $PACKAGE_LOCATION/Packages location. But I am using bash script and looping over ls content is fragile. Other mechanism I thought of trying is using rpm -qa but this queries all installed (and not downloaded) packages.
Is there anything I can do to get list of all downloaded packages.
Hope if you are looking for what package you have installed that use below command.
rpm -qa | grep packagename
As well as you can use rpm --help to get more flags info.
hope it will help...!!!
I've freshly installed Ubuntu 18.04 and have decided to try Anaconda. However, when I then try to install Mendeley, I get the following error:
mendeleydesktop depends on python; however:
Package python is not installed.
I assume the issue here is that python is now in ~\anaconda2\bin, instead of \usr\bin. I'm not certain what I should do. As I see it, I have 3 options:
Install a system python into \usr\bin, but this seems sloppy/messy
Put a softlink in \usr\bin along the lines of ln -s python ~\anaconda2\bin\python, but I'm worried that there might be implications to that, which I don't understand
Somehow tell the mendeley.deb file where the python I'm using is, but I don't know how to do this.
Are either 1 or 2 reasonable options? If not how do I implement my 3rd option, or what else should I do?
Empirically found option 2 does not work. dpkg is still looking for the installation of the python package
You can use the method given here to remove the system python dependency in the .deb file; I tried this and mendeley seems to install as normal. Assuming your conda environment is set up correctly, it will work. I had to modify the instructions on that page slightly:
Unpack deb: $ ar x mendeleydesktop_1.19.4-stable_amd64.deb (will create i.e. three files: debian-binary control.tar.gz data.tar.gz)
Unpack control archive: $ tar xzf control.tar.gz (will create: postinst control)
Fix dependencies in control (use a text editor)
Repack control.tar.gz: $ tar c postinst control | gzip -c > control.tar.gz
Repack deb: $ ar rcs mendeleydesktop_1.19.4-stable_amd64_nopythondep.deb debian-binary control.tar.gz data.tar.gz (order important! dpkg wouldn't be able to read the metadata of a package quickly if it had to search for where the data section ended!)
Environment is AIX 7.0 RPM Version 3.0.5 . I am very new to Unix world, Please be patient with my ignorance.
We have 3 different types of files to be packaged as RPM.
• Source/binary/*.bainaryfiles (around 160 of them)
• Source/ui/*.mm (No of files 2)
• Source/scripts/*.sh (10 to 20)
These files are compiled for the target server and these are in binary form and we don’t want to compress these files to tar.
When the install happens on the Generated RPM using rpmbuild the .binaryfiles ,.ui and .sh files have to go to different directories on the target server
No build has to happen since its already built.
Can anybody provide me the .spec file sample and the steps.
can we run rpmbuild without root access?
Can we run the install of the rpm without root access?
Here is an example that doesn't have any build section.
Name: special-package
Version: 0.0
Release: 0.1
Summary: This is a special package
Group: Devlopment/Tools
License: Special Proprietary
BuildArch: noarch
%description
This package contains some special stuff
%install
# e.g., on the target server path_to_all_binary_files=/usr/share/special/bin
%{mkdir_p} %{buildroot}%{_path_to_all_binary_files}
# In case of a copy, file permissions will be copied as it is.
# You can also try 'install -m 755 $RPM_SOURCE_DIR/....'
# 'man install' for more information
%{__cp} $RPM_SOURCE_DIR/binary/*.binaryfiles %{buildroot}%{_path_to_all_binary_files}
# Similarly do this for other sets of files
%files
%{_path_to_binary_files}/*.binaryfiles
%{_path_to_sh_files}/*.sh
%changelog
* Tue Mar 14 2017 Name Surname<name.surname#email.com>
- First build of the special package
This one is by Fedora, but I think a lot of guidelines apply in general
https://fedoraproject.org/wiki/How_to_create_an_RPM_package
I have been trying to build the freetype2 library in OSX Mavericks for several weeks now, but without success.
The trouble is with using GNU Autotools to create the configure build script.
I have installed automake, autoconf, libtoolize, m4 and perl5 using the macports port command.
When executing aclocal, there is supposed to be a file created in the configure directory that contains Autotools macros: aclocal.m4. However, this file is not being output, and the subsequent glibtoolize and autoconf commands are generating a spurious configure script.
The result is: no aclocal.m4 file, and the usual contents of ./autom4te.cache/traces.* being dumped at the top of the generated configure file (the traces.* files are empty).
e.g.:
m4trace:configure.ac:14: -1- AC_SUBST([SHELL])
m4trace:configure.ac:14: -1- AC_SUBST_TRACE([SHELL])
m4trace:configure.ac:14: -1- m4_pattern_allow([^SHELL$])
Any help would be greatly appreciated.
GNU Autotools does not support execution over a working directory stored on a FAT32 file system. It results in spurious m4trace debug messages being output to the generated configure script.
It is unknown why this is, but may be related to the reliance on the sleep command to check whether a file has changed. FAT32 rounds time stamps to the nearest second, where execution and subsequent modification checks may happen on a sub-second timescale.
This has been raised with the development team, but for now, I move my working directory to my OSX boot partition before executing GNU Autotools.
I have a number of common functions that I would like to source, so it's available in the debian maintainer scripts (preinst/postinst/prerm/postrm), call it common.sh.
If I add "common.sh" to the DEBIAN directory, dpkg complains:
dpkg-deb: warning: conffile '' is not a plain file
dpkg-deb: warning: ignoring 1 warning about the control file(s)
However, the package builds properly.
When I install, it's difficult to find the proper directory where my common.sh exists. In preinst it seems to be looking for /var/lib/dpkg/tmp.ci, while in postinst it seems to look for /var/lib/dpkg/info.
I could stick the common.sh in a tmp directory and delete it later, but I get the feeling that files installed to the OS should remain their until dpkg can remove them.
At any rate, I'm wondering what the true 'debian' way of doing this would be?
The preinst is run from some implementation defined directory because the package isn't unpacked into its proper location in the filesystem yet.
I'm pretty sure forcing extra files into the DEBIAN part is not allowed for standard packages. You could install common.sh into the filesystem, usually under /usr/share/yourpackagename/, and the use it from the postinst and prerm scripts.
It doesn't work for preinst and postrm as the package contents are not available then.