I'm trying to create an RPM of some software we have from an external entity. THey provide us with tarballs of 32bit binaries, and 64bit binaries.
I'm wondering what is the best way to create a spec file which could handle both types of binaries.
I tried something like :
%prep
%ifarch i686
# Use Source0 (32bit)
%setup -c -T -a 0
%endif
%ifarch x86_64
# Use Source1 (64bit)
%setup -c -T -a 1
%endif
But this is giving me back :
+ %setup -c -T -a 1
/var/tmp/rpm-tmp.67731: line 25: fg: no job control
error: Bad exit status from /var/tmp/rpm-tmp.67731 (%prep)
I'm guessing this is due to the -a option given to %setup, which I believe means "change directory first, then extract source $arg1.
Is there a better way to do this?
I am not sure what is contained in your Source0 or Source1, but likely they are not tarballs so I see no reason to call %setup. Instead work with them like this:
%prep
#no %setup
%ifarch i686
#use %{SOURCE0}
%endif
%ifarch x86_64
#use %{SOURCE1}
%endif
Related
In the following example, I expected the error message to come from xyz, not from getopt. What am I doing wrong?
/tmp> getopt --name xyz --options "xyz:" -- -x
-x --
/tmp> getopt --name xyz --options "xyz:" -- -x -z
getopt: option requires an argument -- z
-x --
How do I make it say xyz: option requires an argument -- z; isn't that what --name is for?
UPDATE
Seems to be a bug. My getopt comes from cygwin
$ getopt --version
getopt from util-linux 2.25.2
It seems to be bug in some versions of the program.
It works for me in in Centos 7.3 and Fedora 19
[vps1 ~]$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
[vps1 ~]$ getopt --name xyz --options "xyz:" -- -x -z
xyz: option requires an argument -- 'z'
-x --
[vps1 ~]$ getopt -V
getopt from util-linux 2.23.2
But it doesn't in my MinGW shell (from Git for Windows)
$ getopt --name xyz --options "xyz:" -- -x -z
getopt: option requires an argument -- z
-x --
$ getopt -V
getopt from util-linux 2.26.2
Update: It works also in 2.27.1 in Linux. And it doesn't work in (at least some version of) Cygwin. So the problem seems to be in the Windows ports (both Mingw and Cygwin, interestingly).
I'll throw a wild guess (not big probability of hitting the target):
The getopt program, since this commit tries to deal with some environnments (in particular, BSD; not Linux) that have/use the getprogname/setprogname to get/set the "current" program name (instead of relying on argv[0]).
#if defined (HAVE_SETPROGNAME) && !defined (__linux__)
setprogname(name);
Now, let's imagine that
Cygwin and MinGW/Msis both support those functions.
However, they lack the HAVE_SETPROGNAME define
Further, their getopt functions (mind you, not the program), just like the BSD version, use getprogname instead of argv[0]
In that case, the problem would be explained. However, I'm skeptical - of point 3 especially.
This is a bug (or just a non-portability issue) which is already fixed in util-linux 2.28, by commit 30fbf2f6. Before this fix it worked only on Linux, OSX and a few BSD flavors but not on WIN32 or GNU-Hurd for example.
If you can't upgrade util-linux (might be difficult to build on windows), then you could use this shell workaround:
bash -c 'exec -a "XYZ" getopt --options "xyz:" -- -x -z'
Note that still using the --name option would override this trick again once if getopt will be updated one day.
Of course you could also simply copy/link/rename the getopt program to whatever name you want.
I'm just learning making rpm packages for some custom builds of software that gets compiled from source (some legacy stuff needs this, so I'm trying to learn, as some packages can't use the latest versions), but hitting an error (I'm doing this in Vagrant, and also as root, but typically I'm trying not to use root as I'm aware it has potential for damage, its just this example seems to need some root changes).
sudo rpmbuild -ba testspec.spec --define "_topdir /tmp/"
So far it looks to be using the directory I expected, /tmp/rpmbuild
make[2]: Entering directory `/tmp/rpmbuild/BUILD/exim-4.80.1/build-Linux-x86_64/pdkim'
make[2]: `pdkim.a' is up to date.
make[2]: Leaving directory `/tmp/rpmbu
But then I see these errors...
/usr/lib/rpm/brp-compress: line 8: cd: /tmp/BUILDROOT/custom-exim-4.80.1-1.x86_64: No such file or directory
+ /usr/lib/rpm/brp-strip
find: `/tmp/BUILDROOT/custom-exim-4.80.1-1.x86_64': No such file or directory
+ /usr/lib/rpm/brp-strip-static-archive
find: `/tmp/BUILDROOT/custom-exim-4.80.1-1.x86_64': No such file or directory
+ /usr/lib/rpm/brp-strip-comment-note
So it now seems to be looking in /tmp/BUILDROOT
I'm new to rpmbuild, and don't quite understand some of the process.
My test spec file is at...
%define myversion exim-4.80.1
##%define mybase %{getenv:HOME}
%define mybase /tmp
%define _topdir %{mybase}/rpmbuild
%define _tmppath %{mybase}/rpmbuild/tmp
%define name custom-exim
%define release 1
%define version 4.80.1
%define buildroot %{_topdir}/%{name}-%{version}-root
BuildRoot: %{buildroot}
Summary: %{name}
Name: %{name}
Version: %{version}
Release: %{release}
Source0: ftp://exim.noris.de/exim/exim4/old/exim-4.80.1.tar.gz
License: GPLv1+
Group: Language
AutoReq: no
AutoProv: no
Requires: db4-devel pcre-devel libdb-devel libXt-devel libXaw-devel
%description
Custom Exim Build
%prep
#Do the following manually before building rpm
#mkdir -p /tmp/rpmbuild/BUILD /tmp/rpmbuild/SPECS /tmp/rpmbuild/SOURCES /tmp/rpmbuild/BUILDROOT /tmp/rpmbuild/RPMS /tmp/rpmbuild/SRPMS
#wget ftp://exim.noris.de/exim/exim4/old/exim-4.80.1.tar.gz -O /tmp/rpmbuild/SOURCES/exim-4.80.1.tar.gz
%setup -q -n %{myversion}
grep exim /etc/passwd || useradd -c "Exim" -d /var/spool/exim -m -s /bin/bash exim
%build
# exim needs to config changes before compiling, may do these first and repackage
cp %{mybase}/rpmbuild/BUILD/%{myversion}/src/EDITME %{mybase}/rpmbuild/BUILD/%{myversion}/Local/Makefile
cp %{mybase}/rpmbuild/BUILD/%{myversion}/exim_monitor/EDITME %{mybase}/rpmbuild/BUILD/%{myversion}/Local/eximon.conf
sed -i -e 's/EXIM_USER=$/EXIM_USER=exim/g' "%{mybase}/rpmbuild/BUILD/%{myversion}/Local/Makefile"
sed -i -e 's/LOOKUP_DNSDB=yes/#LOOKUP_DNSDB=yes/g' "%{mybase}/rpmbuild/BUILD/%{myversion}/Local/Makefile"
make
%install
rm -rf $RPM_BUILD_ROOT
#%{__mkdir_p} '%{buildroot}%{_sbindir}'
make install
%clean
rm -rf $RPM_BUILD_ROOT
%post
%postun
%files
Why is it using /tmp/BUILDROOT literally, instead of /tmp/rpmbuild, and are there other obvious things I'm doing wrong ? I've looked at a lot of other tutorials on rpmbuild, but aren't very clear on best practices or what happens during each phase.
Since the buildroot parm is not passed to rpmbuild, the default path is being used by your spec file:
BuildRoot: %{buildroot}
Try adding the buildroot parm... Add buildroot /tmp/rpmbuild to --define
Or if using a makefile:
BUILD_TMP=/tmp/rpmbuild
TOP_DIR=/tmp
rpmbuild -bb
--buildroot $(BUILD_TMP)
--topdir $(TOP_DIR)
$(SPEC_DIR)/testspec.spec
In my case rpm-build was missing.
So sudo yum install rpm-build solved the problem. Or if you use puppet:
package { 'rpm-build':
ensure => latest,
}
I am working on making an rpm for a small program used within our enterprise. The %build section of the rpm process works. I'm having trouble with the install section. I've referenced this article response and I believe I am properly referring to the target location with respect to %{_buildroot}.
The program I'm making is to be installed as a system service. So, after the rpm actually is generated for this step, I've got to add the next step in my installation process which is to include the script that is installed to the init.d location and run that install. One step at a time though.
The build errors are as follows (omitting everything but %install):
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.eUDaCK
+ umask 022
+ cd /home/packager/rpmbuild/BUILD
+ '[' /home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64 '!=' / ']'
+ rm -rf /home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64
++ dirname /home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64
+ mkdir -p /home/packager/rpmbuild/BUILDROOT
+ mkdir /home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64
+ cd o2arbitord-1.0
+ LANG=C
+ export LANG
+ unset DISPLAY
+ install -m 555 /home/packager/rpmbuild/BUILD/o2arbitord-1.0/o2arbitord /home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64/usr/sbin
install: cannot create regular file `/home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64/usr/sbin': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.eUDaCK (%install)
Now, my rpmbuild directory does not have the directory /home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64/usr/sbin. While I know that's part of the problem, the rpmbuild process isn't making the directory /home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64 either. What I don't understand about that one is: why? Looking at the script output above you can clearly see the line: mkdir /home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64. So, why isn't the directory made?
How does the line BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) from whatever the definition of %{_buildroot} is? I thought that was the definition, but it appears to be something different.
For reference, my spec file
Name: o2arbitord
Version: 1.0
Release: 1%{?dist}
Summary: a daemon
Group: Applications/System
License: GPL
URL: http://My.site
Source0: %{name}-%{version}.tar.gz
BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
BuildArch: x86_64
BuildRequires: libusb1-devel
#Requires:
%description
%prep
%setup -q
%build
make -f o2arbitord.mk
%install
install -m 555 %{_builddir}/%{name}-%{version}/%{name} %{buildroot}%{_sbindir}
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
/usr/sbin/o2arbitord
%changelog
You are attempting to install a file into a directory that doesn't exist (yet).
RPM only creates the %{buildroot} for you automatically. Anything under that you need to create yourself.
So when you run
install -m 555 %{_builddir}/%{name}-%{version}/%{name} %{buildroot}%{_sbindir}
where %{buildroot}%{_sbindir} expands to /home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64/usr/sbin RPM has only created /home/packager/rpmbuild/BUILDROOT/o2arbitord-1.0-1.el6.x86_64 for you already.
You need to create the /usr/sbin part of that path and then copy the file into it.
You can do that with either
%{__mkdir_p} '%{buildroot}%{_sbindir}'
or
%{__install} -d '%{buildroot}%{_sbindir}'
Where
$ rpm -E '__mkdir_p = %{__mkdir_p}'
__mkdir_p = /bin/mkdir -p
$ rpm -E '__install = %{__install}'
__install = /usr/bin/install
Instaling PGPLOT the install gets stopped for ever here:
$ cpanm PGPLOT
--> Working on PGPLOT
Fetching http://www.cpan.org/authors/id/K/KG/KGB/PGPLOT-2.21.tar.gz ... OK
Configuring PGPLOT-2.21 ... OK
Building and testing PGPLOT-2.21 ...
Looking at the Build.log seems that it is waiting for a prompt answer
$ tail ~/.cpanm/build.log
-L/usr/lib -L/usr/local/lib -lcpgplot -lpgplot -lX11 -lpng -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib -lgfortran -lm \
chmod 755 blib/arch/auto/PGPLOT/PGPLOT.so
cp PGPLOT.bs blib/arch/auto/PGPLOT/PGPLOT.bs
chmod 644 blib/arch/auto/PGPLOT/PGPLOT.bs
Manifying blib/man3/PGPLOT.3
make: warning: Clock skew detected. Your build may be incomplete.
make: Warning: File `Makefile' has modification time 3e+02 s in the future
PERL_DL_NONLAZY=1 /home/pmg/perl5/perlbrew/perls/perl-5.16.0/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
Default Device for plot tests [recommend /XSERVE] ?
How can I avoid this question either forcing defaults or given the option through env. vars?
[UPDATE] FIX
From the Russell answer I exported the variable for device
export PGPLOT_DEV=/XSERVE; cpanm PGPLOT
And connected with x11vnc to the server (to the main display) for closing all windows the pgplot test was displaying.
[NOTE] don't try to install pgplot perl lib under screen even with ssh -X, chances are that you are not in the same computer you starter your original screen and the X redirection will not work. You can circumvent that limitation with a vnc connection to main display or you will not being able to finish the installation. xrdp and other vnc that open a new session will not work. You need to share the main display.
From reading test.pl in the distribution, it checks the PGPLOT_DEV environment variable. It looks like the valid values are /XSERVE for Unix/Linux and /PNG for Windows.
I'm writing a package installer script in Perl. I need a command (probably OS command) that returns a simple 0 or 1 to the caller script if a Ubuntu/Debian package is installed or not.
I've tried
dpkg -s
It always returns 0.
dpkg -L
almost works but if the user does not
apt-get --purge remove
the packages, some files are left and always returns 0
I don't want to grep text - a simple true or false is what I need.
Any ideas?
#Andy:
aptitude remove unixodbc -y
dpkg-query -W unixodbc; echo $?
unixodbc 2.2.11-21
0
aptitude install unixodbc -y
dpkg-query -W unixodbc; echo $?
unixodbc 2.2.11-21
0
Maybe not ideal, but this works:
dpkg -s "$package" | grep '^Status:' | grep -q ' installed'
Or just
dpkg -s "$package" | grep -q '^Status:.* installed'
I think this does it:
test -n "`aptitude search '?name(^packagename$)~i'`"
Won't work on virtual packages.
If you're going to use the dpkg database, I concur with the "use grep" suggestions. Weighing the possibility that the output format of the package tools changes against the complexity of the alternative solutions, it's probably better to use grep.
That said, here are some possibilities:
use dpkg --get-selections. The exit status is always zero, but the output is very simple: <package><white space><status>. This is the "requested state" (install/hold/deinstall/purge), which can differ from the actual package state, but usually won't.
use one of the utilities in the dctrl-tools or dpkg-awk packages
implement a test that directly determines whether the dependency is present, e.g., use pkg-config, or search for a program in PATH. This has the advantage that it will allow the install to continue on systems where the dependency has been built by hand and installed without the knowledge of the package manager. This also makes your install script more portable.
you may want to look in to PackageKit