I’m planning to build conky 1.9.1 prerelease 2430 in OBS. Do you guys think it would make sense to name the package conky-1.9.1_pre2430? Or should I rather name it conky-1.9.1?
# zypper in conky-1.9.1_pre2430-0.x86_64.rpm
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following package is going to be upgraded:
conky
1 package to upgrade.
Overall download size: 662.1 KiB. After the operation, additional 24.0 B will be used.
Continue? [y/n/?] (y): y
Retrieving package conky-1.9.1_pre2430-0.x86_64 (1/1), 662.1 KiB ( 2.9 MiB unpacked)
Retrieving package conky-1.9.1_pre2430-0.x86_64 (1/1), 662.1 KiB ( 2.9 MiB unpacked)
Installing: conky-1.9.1_pre2430-0 ...........................................................................[done]
# conky -v
Conky 1.9.1_pre2430 compiled Thu Oct 4 09:24:58 PDT 2012 for Linux 3.4.6-2.10-desktop (x86_64)
Compiled in features:
System config file: /etc/conky/conky.conf
Package library path: /usr/lib64/conky
X11:
* Xdamage extension
* XDBE (double buffer extension)
* Xft
* ARGB visual
Music detection:
General:
* math
* hddtemp
* portmon
* Curl
* RSS
* wireless
* support for IBM/Lenovo notebooks
* nvidia
* config-output
* Imlib2
* apcupsd
* iostats
* ncurses
* Lua
Lua bindings:
* Cairo
* Imlib2
> I’m planning to build conky 1.9.1 prerelease 2430 in OBS. Do you guys
> think it would make sense to name the package conky-1.9.1_pre2430? Or
> should I rather name it conky-1.9.1?
>
If I understand correct, v1.9.1 is not released yet.
So you should not set 1.9.1 for your package version.
After 1.9.1 released your 1.9.1_pre2430 version is newer:
% zypper versioncmp 1.9.1_pre2430 1.9.1
1.9.1_pre2430 is newer than 1.9.1
I’m still building locally for now. I tried this name 1.9.1~pre+2430, and it works fine:
$ zypper vcmp 1.9.1~pre+2430 1.9.0
1.9.1~pre+2430 is newer than 1.9.0
$ zypper vcmp 1.9.1~pre+2430 1.9.1
1.9.1~pre+2430 is older than 1.9.1
also used autogen.sh in %build, as suggested by Malcolm.
I don’t know how/where to use “rpmlib(TildeInVersions)”, couldn’t find an example in a spec file. It didn’t complain without (locally though), but would fail to install if I added this:
Requires: rpmlib(TildeInVersions)
It can not be the right syntax or the correct way to use it.
Further the version I just built today now says that:
Conky **1.9.1_preNONE** compiled Fri Oct 5 04:16:46 PDT 2012 for Linux 3.4.6-2.10-desktop (x86_64)
This is my package:
# rpm -qa conky
conky-1.9.1~pre+2430-0.x86_64
Thus my package name is wrong now. I don’t know how to check the git version nor how versions and prereleases are organized in git.
Humm … I see why I get prerelease “NONE”.
from autogen.sh:
# identify a git revision similar to svn based on number of commits, if a git
# working copy. the last svn commit was rev 1274, so we'll pick up from there
if test "$1" != "" && test -d "$1/.git"; then
revision=`git log --since=2008-12-06 --pretty=oneline | wc -l | awk '{print $1 + 1274}'`;
elif test -d ".git"; then
revision=`git log --since=2008-12-06 --pretty=oneline | wc -l | awk '{print $1 + 1274}'`;
else
revision="NONE"; fi
# generate configure.ac with substituted git revision
sed -e "s/@REVISION@/${revision}/g" < "configure.ac.in" > "configure.ac"
Got it! If I want the program to display the correct revision number while running autogen.sh from within the rpm %build, I have to include the .git directory in the archive. It makes the tarball only 25 times larger. lol!
There must be an easier way…
$ conky -v
Conky 1.9.1_**pre2430** compiled Fri Oct 5 18:07:58 PDT 2012 for Linux 3.4.6-2.10-desktop (x86_64)
...
I’m trying to build it in OBS now and it fails to install the manpage:
239s] Making install in doc
239s] make[1]: Entering directory `/home/abuild/rpmbuild/BUILD/conky-1.9.1~pre+2430/doc'
239s] make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/conky-1.9.1~pre+2430/doc'
239s] make[2]: Nothing to be done for `install-exec-am'.
239s] /usr/bin/mkdir -p '/home/abuild/rpmbuild/BUILDROOT/conky-1.9.1~pre+2430-5.1.x86_64/usr/share/man/man1'
239s] /usr/bin/install -c -m 644 ./conky.1 '/home/abuild/rpmbuild/BUILDROOT/conky-1.9.1~pre+2430-5.1.x86_64/usr/share/man/man1'
239s] /usr/bin/install: cannot stat './conky.1': No such file or directory
239s] make[2]: *** [install-man1] Error 1
239s] make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/conky-1.9.1~pre+2430/doc'
239s] make[1]: *** [install-am] Error 2
239s] make[1]: Leaving directory `/home/abuild/rpmbuild/BUILD/conky-1.9.1~pre+2430/doc'
239s] make: *** [install-recursive] Error 1
239s] error: Bad exit status from /var/tmp/rpm-tmp.ocy2Bi (%install)
I suspect it might be because of running autogen.sh and the instruction might be missing somewhere. … but just guessing. I can build the package locally (with manpage).
since some OBS( like Packman OBS) will parse + as %30 and “_” is ugly for a rpm.
Use 1.gz. OBS automatically compresses them into gz. it’s a distro feature to save user space.
Actually you can just fork conky in server:monitoring and change %define PMBS_BUILD from 0 to 1 to enable nvidia support. that’s the only difference between your package and the standard one. So now you don’t need to bother the sub-package split thing. just
osc linkpac server:monitoring conky your_prj
and make some change through the web interface.
Actually the most ugly stuff in your packaging is the changelog part. you have to separate a .changes file and write changelog there instead of in the specfile. later .changes will be parsed into specfile thus compatible for every rpm distribution.
W: no-url-tag << you have to add a Url: http://blabla.com tag
W: invalid-license GPL v2 << you have to change GPLv2+ to GPL-2.0+. see license.opensuse.org
W: explicit-lib-dependency libxslt-tools << you have to remove Requires: libxslt-tools somewhere in specfile
W: standard-dir-owned-by-package /usr/bin << you can’t own /usr/bin by %dir
W: non-conffile-in-etc << you have to use %config %{_sysconfigdir}/conky/conky.lua in %files section
It doesn’t work - it won’t get updated, as @RedDwarf noticed earlier:
wrong:
$ zypper vcmp 1.9.1.pre2430 1.9.1
1.9.1.pre2430 is newer than 1.9.1
correct:
$ zypper vcmp 1.9.1~pre+2430 1.9.1
1.9.1~pre+2430 is older than 1.9.1
However older releases as well as other distros won’t build in OBS because of the tilde. And I still don’t know indeed how to use “rpmlib(TildeInVersions)” It might have worked under 12.2 - at least it didn’t complain but didn’t find the manpage.
I know. But what do I do concretely to build this package in OBS? While building locally, this doesn’t produce an error:
make[2]: Nothing to be done for `install-exec-am'.
/usr/bin/mkdir -p '/home/openSUSE/agnelo/rpmbuild/BUILDROOT/conky-1.9.1~pre+2430-0.x86_64/usr/share/man/man1'
/usr/bin/install -c -m 644 conky.1 '/home/openSUSE/agnelo/rpmbuild/BUILDROOT/conky-1.9.1~pre+2430-0.x86_64/usr/share/man/man1'
and the file in $RPM_BUILD_ROOT/usr/share/man/man1 is indeed compressed.
I did previously. But I had other problems which have been discussed in the other thread. In my attempts to get it work, I tried different solutions, including this conky build, which works fine too. The other difference with the version in server:monitoring is that apcupsd works (see my patch). In server:monitoring, it is enable, but doesn’t work. It actually doesn’t work since 1.8.1 without this patch. It’s a well known problem among conky users. I monitor UPS with conky on any machine here (see the picture in this post http://forums.opensuse.org/english/get-technical-help-here/how-faq-forums/unreviewed-how-faq/464737-easy-configuring-conky-conkyconf-5.html#post2487092). The APC Back-UPS status won’t show up with the version from server:monitoring. … and by the way, I had 1.9.0 packaged and working before it was ever available in server:monitoring or anywhere else. Thus they should have forked conky from my repo.
I’m trying to figure out which packages you are talking about.
That’s fine. But my days would have to be 72 hours long instead of 48 to ever have a chance to act as a qualified distribution packager. I build whatever is missing or try to fix whatever is buggy when I can’t afford to wait for other people to fix it, but I do not consider myself as a distribution packager. I’ll see what I can do better though to improve my packaging style - but don’t look at my programming style or you’ll get a shock. lol!
