I am trying to get USER-NAME in my spec file while packaging rpm. "$HOME" command gives me USER in case of running in bash.
Spec file also works like bash but when I run the similar command in %post section of spec file, I get 'root' as output.
This might be happening as user run rpm package using sudo.
Kindly help how to get USER name in Spec file
In the .spec a %define macro would get you the username. Here is an example, how it might look like inside the .spec file.
Source0: %{name}-%{version}.tar.gz
# User defined function to get who built the RPM
%define packagername %(who am i | awk '{print $1}')
%description
...
%prep
...
# Then in the post section call the macro %{packagername}
%post
echo "Packager is: %{packagername}"
Note, %post section will be run only when install the .rpm file. Above will print the information into stdout.
Output
$ sudo rpm -ivh simple-0-1.x86_64.rpm
Preparing... ########################################### [100%]
1:simple ########################################### [100%]
Packager is: iamauser
In order to use this macro globally on the system, one can define it inside /etc/rpm/macros.<somename>.
$ cat /etc/rpm/macros.username
# Get who is the packager
%packagername %(who am i | awk '{print $1}')
With the global definition one doesn't need to define it inside the .spec file.
If you don't have permission to write into /etc/rpm, then defining it in ~/.rpmmacros file would make that macro available only to you.
Related
I am packaging some Python libraries as RPMs. Some of the libraries are only available as source distributions (no wheels).
In my RPM spec I do:
pip install --root=%{buildroot} --prefix=/x/y tornado
When rpmbuild finishes up it runs check-buildroot, and the build fails with errors like:
Binary file /a/b/c/BUILDROOT/my-rpm-1.0.0-1.el7.x86_64/x/y/lib64/python2.7/site-packages/tornado/speedups.so matches
I see the %{buildroot} path listed if I run strings tornado.so | grep BUILDROOT.
How can I sanitize the .so files? Or more generally, how can I make check-buildroot pass?
I figured out how to remove the paths from the SO files.
I determined that the paths were embedded debug information using this command:
readelf --debug-dump=line speedups.so | less
The strip command can remove debug information from SO files, so I added this to my RPM spec:
BuildRequires: binutils
set +e
find "%{buildroot}{%_prefix}/lib64/python2.7/site-packages" -type f -name "*.so" | while read so_file
do
strip --strip-debug "$so_file"
done
set -e
Note: strip segfaults on some SO files, and it's not clear why. I disabled immediate exits with set +e so that the build ignores them.
I am trying to compile grammar parser https://github.com/RichardMoot/Grail into Linux program according to instructions https://github.com/RichardMoot/Grail/blob/master/README and http://www.labri.fr/perso/moot/tutorial/install.html. There is manual how to create Linux executable from SWI-Prolog code http://www.swi-prolog.org/FAQ/UnixExe.html. All that is fine. But I can not find in the Makefile https://github.com/RichardMoot/Grail/blob/master/Makefile any compilation command. SWI-Prolo uses swipl command for compilation but this Makefile swipl calls only once - for displaying the version of the swipl.
I experience some hardship in installation and compilation, that is fine, I can execute/debug Makefile line by line and arrive at the result. But there is problem in my case - I can not see the ultimate goal in my makefile: which lines are responsible for the production of object files (if necessary) and which lines are responsible for the creation of the final Linux executable.
This is windowed program. The source code and documentation contains warnings about incompatibility with the SWI-Prolog 7, but that is fine, I can resolvem them myself, but as I said - I can not see the Makefile lines for creation of exe.
The source code is created by eminent scientist and I certainly don't want to disturb him by so low-level technical question. I would be happy if he continues work on theory and doesn't waste time on low level programming questions. Hope, that there are SWI-Prolog experts.
I am using latest (7.x) SWI-Prolog on Ubuntu 16.x and I have already installed all the mentioned prerequisites.
If you look closely at the provided Makefile, you'll find that the rules all and install are defined as follows (comments added by me):
all:
-cd source ; $(edit) g3 > g3.tmp # Replaces placeholders for your
# ... GRAIL_ROOT install directory.
-cd source ; mv -f g3.tmp g3 # Overwrites `g3` with the filled file.
cd source ; chmod a+x g3 # Makes it executable.
install: # Essentially copies all files to
-mkdir $(datarootdir) # ... your install directory.
-mkdir $(datadir)
cp -f $(images) $(datadir)
-mkdir $(bindir)
cp -f source/insertdot $(bindir)
chmod a+x $(bindir)/insertdot
cp -f $(resources) $(datadir)
cp -f source/*.pl $(bindir)
cp -f source/g3 $(bindir)
If you then do the common make && make install you'll end up with two folders installed in your Grail directory: bin and share. Inside the binary directory you'll have the g3 file that, regardless of being a SWI-Prolog source, has this initial line:
#!/usr/bin/swipl -q -g start -f
% [... prolog code.]
This header should allow your console terminal to determine what interpreter to use for this script (in this case, swipl). In my case, executing Grail with ./g3 returned a SWI-Prolog message indicating that wrong options/command arguments were used.
According to the man, Unix systems have to use option -s at the end of the header (but this didn't work either in my case):
From the manual:
-s file
Load file as a script. This option may be used from the shell to
make Prolog load a file before entering the toplevel.
It is also used to turn a file into an executable Prolog script
on Unix systems using the following first line
#!/usr/bin/swipl option ... -s
If you want to run this program, simply call the same command from your terminal:
swipl -q -g start -s g3
As I understand it, the purpose of the Source: header in an rpm spec file is to specify a file (often a tar archive) that is used as the package payload. This source file is typically generated beforehand, perhaps by make, and then rpmbuild is executed afterwards.
I'm wondering if it's possible to cut make out of the picture and just use rpmbuild. Can the source file be created as part of the rpmbuild process itself, perhaps in the %build or %install step in the spec file?
If so, what does one use as the Source: header? I can't just leave it blank, because rpmbuild complains. Is there a way to tell rpm that the payload file is generated from within the spec file, and not supplied externally?
I don't want to create the source file separately because that would mean keeping track of the package name and version number in two places: in the rpm spec file, and also in whatever makefile or other script creates the payload file. It seems like I should be able to do everything from within the spec file.
You want to call
%setup -q -c -T
see [1]. Example:
Name: test
Version: 1
Release: 1%{?dist}
Summary: Test
License: ...
%description
Test
%prep
%setup -q -c -T
%build
echo "int main() { return 0; } " > test.cpp
gcc -o test test.cpp
%install
install -Dpm 0755 test %{buildroot}%{_bindir}/test
%files
%{_bindir}/test
%changelog
...
[1] http://www.rpm.org/max-rpm/s1-rpm-specref-macros.html
I had the a similar problem recently. I ended up writing a script that read the spec file and did all the work. We no longer had to manage Makefiles and spec files and whatever other ways some of our developers were managing this.
The script is publicly posted on github at:
https://github.com/alexnelsone/jenkins-rpm-build/blob/master/README.md.
It parses the info out of the spec file and then does all the work for you.
Passing User defined argument to RPM is possible while installing?.
for example:
~>rpm -i sample.rpm -license_path=/path/
or
~>rpm -i -license_path=/path/ sample.rpm
or
~>rpm -i -somearg sample.rpm
-Sakthi
RPMs aren't meant to take user defined arguments.
See RPM - Install time parameters
Another similar question is at https://superuser.com/questions/408852/is-it-possible-to-get-users-input-during-installation-of-rpm
One workaround is to have the rpm's postinstall script ask for input from stdin, in which case you can pass in the answers by redirecting stdio from a file or here document.
>rpm -i sample.rpm <<__NOT_RECOMMENDED__
somearg
__NOT_RECOMMENDED__
It looks like you are trying to create a relocatable RPM.
In the preamble of your .spec file, put the prefix of the file path that can be relocated.
For example, if the full path to your file is
/base/path/to/my/file
then /base can be changed during RPM installation but /path/to/my/file will remain the same.
Here's what you put in your .spec file:
#Preamble: Summary, Name, etc.
Prefix: /base
Ensure that you mention this prefix while listing all relocatable files in the %install and %files sections in the .spec file. There are conditions where a relocatable RPM may not work, so check out these things to consider as well.
%files
%{prefix}/path/to/my/file
Now when you install the RPM, you can specify a different prefix.
rpm -i sample.rpm --prefix /tmp
This will install the file in /tmp/path/to/my/file.
When I run rpm -qlp I get the file contents of the RPM as you can see below, but when I run rpm --scripts -qp CBS0.0.0_10.0.i386.rpm I get the scripts' contents, but not their filename.
My question is why can't I see the script names in the RPM contents (ie, where does the script s come from?)
$ rpm -qlp CS0.0.0_10.0.i386.rpm
/home/thy_diff/rt
/home/thy_diff/rt/Cerse-zip
/home/thy_diff/rt/Configure_rht.properties
/home/thy_diff/rt/UFE_Install.sh
/home/thy_diff/M_client
/home/thy_diff/M_client/Crse-CLIENT.zip
/home/thy_diff/M_client/Configure_client.properties
/home/thy_diff/M_client/UF_Install.sh
AFAIK scripts are part of RPM package meta-data, there are no files for scripts. The commands of scripts are written directly into spec-file just next to other meta-data like "description" or "license".
For example, see here the %post section. It contains a script of a single command. I believe all other scripts are written just the same.
Try with following command:
rpm -qlp --scripts CS0.0.0_10.0.i386.rpm
You can see the script contents