January 2007 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] [PATCH] default to non-root
by Jan Engelhardt 19 Jan '07

19 Jan '07

Default to non-root builds and recognize "rootforbuild" in specfiles. Signed-off-by: Jan Engelhardt <jengelh(a)gmx.de> Index: build/build =================================================================== --- build.orig/build +++ build/build @@ -46,7 +46,8 @@ RUNNING_IN_XEN= RPMLIST= RELEASE= REASON= -NOROOTFORBUILD= +NOROOTFORBUILD=true +ROOTFORBUILD=false LOGFILE= BUILD_DIR=${BUILD_DIR:-/usr/lib/build} KILL= @@ -711,7 +712,12 @@ while test -n "$1"; do ;; *-norootforbuild) NOROOTFORBUILD=true - ;; + ROOTFORBUILD=false + ;; + (*-rootforbuild) + NOROOTFORBUILD=false + ROOTFORBUILD=true + ;; *-stage) BUILD_RPM_BUILD_STAGE="$ARG" shift @@ -1008,6 +1014,7 @@ for SPECFILE in $SPECFILES ; do echo "BUILD_DIST='${BUILD_DIST//\'/$Q}'" >> $BUILD_ROOT/.build/build.data echo "RELEASE='${RELEASE//\'/$Q}'" >> $BUILD_ROOT/.build/build.data echo "NOROOTFORBUILD='${NOROOTFORBUILD//\'/$Q}'" >> $BUILD_ROOT/.build/build.data + echo "ROOTFORBUILD='${ROOTFORBUILD//\'/$Q}'" >> $BUILD_ROOT/.build/build.data echo "CREATE_BASELIBS='$CREATE_BASELIBS'" >> $BUILD_ROOT/.build/build.data echo "REASON='${REASON//\'/$Q}'" >> $BUILD_ROOT/.build/build.data test -n "$XENSWAP" && echo "XENSWAP='/dev/hda2'" >> $BUILD_ROOT/.build/build.data @@ -1103,12 +1110,16 @@ for SPECFILE in $SPECFILES ; do # # check if we want to build with the abuild user # - BUILD_USER=root - test -n "$NOROOTFORBUILD" && BUILD_USER=abuild + BUILD_USER=abuild + test -z "$ROOTFORBUILD" && BUILD_USER=abuild if test "$SPECFILE" != "${SPECFILE%.dsc}" \ || egrep '^#[ ]*norootforbuild[ ]*$' >/dev/null <$SPECFILE; then BUILD_USER=abuild fi + if test "$SPECFILE" != "${SPECFILE%.dsc}" \ + || egrep '^#[ ]*rootforbuild[ ]*$' >/dev/null <$SPECFILE; then + BUILD_USER="root" + fi if test $BUILD_USER = abuild ; then if ! egrep '^abuild:' >/dev/null <$BUILD_ROOT/etc/passwd ; then echo 'abuild::99:99:Autobuild:/home/abuild:/bin/bash' >>$BUILD_ROOT/etc/passwd #<EOF> -`J' -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] devs in dependencies
by Jan Engelhardt 18 Jan '07

18 Jan '07

Hi, recompiling samba (with my features added of course) using lbuild-10.2 gives the new samba-client-.i586.rpm the dependency for the package "devs". The original samba-client package from the SUSE DVD/FTP/etc. does _not_ have this dependency. lbuild broken? Supposedly. /usr/lib/build/configs/sl10.2.conf contains Macros: %insserv_prereq insserv sed devs Taking devs out solves the problem. 13:52 ichi:../build/configs > rpm -q build build-0.0_SVNr1043M-2.1 -`J' -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] location of devel symlinks for libraries
by Ludwig Nussel 17 Jan '07

17 Jan '07

Hi, A library required during system boot lives in /lib. Therefore one runs configure --lib=/%_lib which means all files get installed into /%_lib including the devel symlink *.so that point to the SONAME. Some packages manually move that symlink to /usr. Does that have any technical or cosmetic advantage? cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 5

[opensuse-packaging] GNOME /usr packaging rules and FAQ
by Stanislav Brabec 16 Jan '07

16 Jan '07

Hallo. I collected several issues you may find during the prefix move to /usr. Contents General rules Files which require special care Obsolete package Obsolete directories Files which should not appear in file list Multiple directory ownership and unowned directories libtool error /opt/gnome/lib/libfoo.la not found Missing icon error General rules You can consult any core GNOME package, if you need an example of a simple spec file. Use as small BuildRequires as possible Watch pc and libtool linking and add correct -devel dependencies. Split out gtk-doc developer documentation to -doc subpackage. Prefer %configure, which already covers many path specifiers and also includes basic CFLAGS and CXXFLAGS. Remove all obsolete configure options. Prevent all force actions (e. g. rm -rf). These actions never fail and probably will remain in the spec file years after they become obsolete. Use %suse_update_desktop_file for all installed icons to allow in-house translation (Factory packages only). Do not use rm -rf $RPM_BUILD_ROOT in install, it opens a security hole. If your patch contains new strings, ask for including to gnome-patch-translation project. Watch carefully, whether the Norwegian hack does not overwrite up-to-date nb.po by outdated no.po. Files which require special care %{_datadir}/mime/packages/*.xml Following scriptlets are needed: %post if test -x usr/bin/update-mime-database ; then usr/bin/update-mime-database usr/share/mime >/dev/null fi %postun if test -x usr/bin/update-mime-database ; then usr/bin/update-mime-database usr/share/mime >/dev/null fi %{_datadir}/locale/*/LC_MESSAGES/*.mo %{_datadir}/gnome/help/* Following modification are needed: %install ... %find_lang foo %files -f foo.lang and exclude files from explicitly listed files Where foo is %{name} or other string depending on base name. For more base names: %find_lang foo %find_lang foo2 foo.lang %{_sysconfdir}/gconf/schemas/*.schemas Following modification are needed: Build system requires: gconf2-devel Preamble: %gconf_schemas_prereq %install ... %find_gconf_schemas or %def_gconf_schemas subpackage1 %add_gconf_schemas schemas_name1 %add_gconf_schemas schemas_name2 %def_gconf_schemas subpackage2 %add_gconf_schemas schemas_name3 %add_gconf_schemas schemas_name4 %end_gconf_schemas schemas names are without path and suffix %pre -f %{name}.schemas_pre %preun -f %{name}.schemas_preun %posttrans -f %{name}.schemas_posttrans %files -f %{name}.schemas_list or %files -f subpackage.schemas_list and exclude files from explicitly listed files In case of more -f needed for one %files: %install ... %find_gconf_schemas %find_lang %{name} cat %{name}.schemas_list %{name}.lang >%{name}.lst ... %files -f %{name}.lst Obsolete package gnome-filesystem This package will be dropped. Directories from it was moved to filesystem or to the package, where it logically belongs. Later there will be created compatibility package for third party packages in /opt/gnome. Obsolete directories %{_datadir}/mime-info %{_datadir}/application-registry These directories are part of obsolete GNOME MIME Info used by GNOME1 and early GNOME2. You should covert it to shared mime info: Consult /usr/share/mime/packages/freedesktop.org.xml. If your MIME type is already there, delete these directories. If not, you have to create MIME description. Call mime-info-to-mime and the delete old contents. As an example see devhelp, gnome-pilot,... Edit resulting xml file and attach it to the bug report to upstream ("Use Shared MIME Info instead of obsolete GNOME MIME Info"). I can send you an automake templates for it. %{_datadir}/gnome/apps Part of GNOME1 menu system. Move it to %{_datadir}/applications, add Categories entry and report to upstream. %{_prefix}/lib/gnome-applets Change it to --libexecdir=%{_prefix}/lib/gnome-panel, which better fits to package name, where it technically belongs. %{_datadir}/mime with exception of %{_datadir}/mime/packages/*.xml These files are auto generated and created by mistake and must never appear in file list. Use --disable-update-mimedb (if implemented) or delete them. See "Special files which require scriptlets" above. %{_libdir}/path/*.*a If "path" is not listed in the *.pc or *-config file, these files are most probably obsolete and should be removed. %{_libdir}/executable or %{_libdir}/path/executable These paths are bi-arch unaware and may cause bi-arch problems. If it is not an upstream problem, you are probably missing --libexecdir. Use --libexecdir=%{_prefix}/lib or --libexecdir=%{_prefix}/lib/%{name} depending on installed path (choose the shortest one which does not install executables directly to %{_prefix}/lib). For GNOME panel applets you can use also --libexecdir=%{_prefix}/lib/gnome-panel. Files which should not appear in file list %{_sysconfdir}/gconf/schemas Use %find_gconf_schemas instead of explicit listing %{_datadir}/locale/*/LC_MESSAGES/*.mo %{_datadir}/gnome/help/* Use %find_lang Multiple directory ownership and unowned directories We are trying to avoid multiple directory ownership as much as possible. Some directories were moved to particular packages. To fulfil directory ownership requirement, you have to add this package to BuildRequires and Requires. If you believe that it is not logical in your case, please contact GNOME team or add "# FIXME: Strange directory ownership" comment to your spec file. If you believe that your package is a good candidate for multiple directory ownership (e. g. you provide branding or module and not require package itself), include directory itself to ownership and comment the reason in the spec file. libtool error /opt/gnome/lib/libfoo.la not found This error most probably means, that one of library providing package was not properly recompiled with libraries in the new location. To find the library, grep /opt/gnome/lib/libfoo.la /usr/lib/*.la /opt/gnome/lib/*.la. Missing icon error If you get a missing icon error, you should most probably link icon from %{_datadir}/icons to %{_datadir}/pixmaps. Choose 48x48, if not possible, use largest smaller or svg file and link it to %{_datadir}/pixmaps. mkdir $RPM_BUILD_ROOT/usr/share/pixmaps ln -s ../icons/hicolor/48x48/apps/foo.png $RPM_BUILD_ROOT%{_datadir}/pixmaps/ In case the path begins with icons/hicolor, it's OK and this hack should disapper once we will be sure, that all desktop menu systems are aware of icons. In case the path does not begin with icons/hicolor (e. g. begins by icons/gnome, report issue as an upstream bug. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 4

[opensuse-packaging] Migrating to Python 2.5 mini-howto
by Jan Matejek 12 Jan '07

12 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, for 10.2 release, we have switched to Python 2.5. It's quite a big change, so here's an assorted list of changes and things to look out for while migrating. toc: 1. pure Python apps and modules 2. C extensions and apps interfacing with Python 3. migrating packages - changes of the standard library 1. pure Python apps and modules Pure Python modules should be largely unaffected, as the majority of changes is backwards compatible. But, be sure to read through the list of changes [1]. Just in case. 2. C extensions and apps interfacing with Python Most of C extension modules will suffer from various problems on 64bit platforms, because of transition to 64bit indices. To sum it up, Python now uses a different type, Py_ssize_t instead of int, for indexing and measuring strings, lists, tuples and dictionaries. Py_ssize_t is the same size as int on 32bit platforms, but it is bigger on 64bits. The change is described in great detail at [2], I'll just list a few guidelines to fix the packages. First and foremost, it's absolutely necessary to fix function calls that use Py_ssize_t as output arguments. Most common are PyString_AsStringAndSize and PyDict_Next, but there are quite a few others. Second, when defining new Python types from C, you need to change certain function signatures: intargfunc becomes ssizeargfunc and must take Py_ssize_t argument, similarly with intintargfunc and other int*funcs. Then there are some lesser tasks - some functions (Py*_Size) return Py_ssize_t, so you should either store it in a proper variable, or check for integer overflow; many others take Py_ssize_t as input... None of this is really necessary to fix, though - if left as is, the extension will work, only it won't be able to access elements beyond int limit. A script [3] can be used to find problems in the extension modules. It also contains lists of affected functions, and provides a bit of interesting insight. It's a must-read for everybody who is going to tamper with C extensions. (I didn't read it at first, and i've regretted it deeply.) There is one more thing that can cause problems: due to a change in Python internal memory allocation, PyMem_* and PyObject_* allocation families are no longer interchangeable. That means that when deallocating a custom type, you need to use PyObject_Del insteand of PyMem_DEL, as many modules now do. If an app or extension is crashing on "invalid free()", it's almost certainly caused by this. Check your code, looking for functions like Py*_Dealloc. 3. migrating packages - changes of the standard library Good news everyone, distutils are back in the core python package. Bad news is that you still need python-devel to do "python setup.py install", because it includes the Makefile necessary for installation. As of now, this is intentional, but it will probably change before 10.3. On this place I'd like to remind everyone of two things: - - since 10.1 distutils install by default into /usr/local. You want to add --prefix=%{_prefix} to the install command in specfile - - Python packages, even pure Python, are not noarch. This is because of /usr/lib vs. /usr/lib64 discrepancy. On 64bit systems, /usr/lib is not in the search path (and yes, this is intentional, because of C extensions), so packages installed there will not work. We'd like to solve this issue somehow, but FHS is limiting, because it doesn't recognize arch-independent library code. In other news, Python 2.5 brings us new additions to the standard library. Part of the ElementTree module is now included. The module has a different name, but many packages out there can already use it. It's inside python-xml subpackate. Another welcome addition is the Sqlite3 module. (sadly it didn't work in intial release, we are now shipping an update) It's in the core package, you don't need to add any dependencies. We also have ctypes, hashlib and wsigref. You can read more about them in [4]. If you have any problems with the transition, feel free to contact me. Regards Jan Matejek [1] http://docs.python.org/whatsnew/other-lang.html [2] http://www.python.org/dev/peps/pep-0353/ [3] http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py [4] http://docs.python.org/whatsnew/modules.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFp3f/jBrWA+AvBr8RAkIDAJ4jB/Hx4NKh2gSqlaQsnC8FAsCOhwCgk6gm hJ7gPwomVwbcfPR/ley3blM= =aRll -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] Python 2.5 porting guide.
by Kai Blin 12 Jan '07

12 Jan '07

Hi folks, Some folks in #opensuse-buildservice told me that Jan Matejek had a "porting C applications to use python 2.5" guide. Is it possible to post it to the list? I figure I'm not the only one besides Jan who currently has a problem with that. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

4 4

[opensuse-packaging] GNOME: planned changes (move to /usr, scriptlets)
by Stanislav Brabec 09 Jan '07

09 Jan '07

Hallo. We are just planning to perform changes in GNOME packaging. It includes: - Long time planned prefix move from /opt/gnome to /usr. - New gconf scriptlets finally provide a correct solution of https://bugzilla.novell.com/show_bug.cgi?id=48114 using %pre, %preun and %posttrans. - To follow upstream names, pkgconfig will be renamed to pkg-config and gtkdoc to gtk-doc. Old names are still available as virtual symbols. - spec file cleanup. It includes removal of obsolete code, unifying packaging scheme, using parallel build, fixing scriptlets, removing obsolete configure options,... Following is optional needs further discussion before starting to do it: - Remove all unneeded .la files. - Do not build static libraries at all. In Build Service: GNOME:STABLE will diverge from FACTORY. GNOME:UNSTABLE just now contains upper mentioned changes. After checking them in, GNOME:UNSTABLE will follow FACTORY. Please don't submit to GNOME:UNSTABLE any more without requesting SuSE people to include your change to FACTORY, otherwise you risk, that your change will be lost. Details: Move to /usr: Just now, all core GNOME packages and many other packages are already moved to /usr in GNOME:UNSTABLE BS project and most problems caused by it is already fixed. We want to do this in FACTORY ASAP. Long waiting will cause a lot of divergences between GNOME:UNSTABLE and FACTORY and will require additional work. You can experience short term failures caused by inconsistence of .la files. You must wait for correct rebuild of all lower level packages. Just now, gnome-filesystem package covers both prefixes, but for openSuSE 10.3, no package should use /opt/gnome (with one compat package exception). It means, that GNOME packages can use %configure to configure all paths (except --libexecdir, see https://bugzilla.novell.com/show_bug.cgi?id=157894). I have prepared a small script - prefixfix, which will help to convert old paths to new ones in the spec file. The rest of changes must be done manually. New scriptlets: As a fix of gconf schemas installation problems, we have a new scriptlet schemas: Macros are defined in gconf2-devel, which must be a part of your build environment. Preamble: %gconf_schemas_prereq %install ... # if your package installs all schemas to one package: %find_gconf_schemas # or # if your package installs schemas to more subpackages: %def_gconf_schemas subpackage1 %add_gconf_schemas schemas_name1 %add_gconf_schemas schemas_name2 %def_gconf_schemas subpackage2 %add_gconf_schemas schemas_name3 %add_gconf_schemas schemas_name4 %end_gconf_schemas # schemas names are without path and suffix %pre -f %{name}.schemas_pre %preun -f %{name}.schemas_preun %posttrans -f %{name}.schemas_posttrans # NOTE: For package with subpackages include name defined in # %%def_gconf_schemas %files -f %{name}.schemas_list or %files -f subpacakge.schemas_list In case of more -f needed for one %files: %install ... %find_gconf_schemas %find_lang %{name} cat %{name}.schemas_list %{name}.lang >%{name}.lst %files -f %{name}.lst -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/

8 15

[opensuse-packaging] perl-Build_module (SuSE-10.2)
by oc2pus＠arcor.de 04 Jan '07

04 Jan '07

Hi, a question according the SuSE-10.2 perl-Module-Build package. It is compiled without C_support. what to use instead, if a perl package has xs files ? as an example: perl-Net-Liblo (http://search.cpan.org/~njh/Net-LibLO-0.05) + perl Build.PL Found pkg-config version 0.20. Found liblo library version 0.23. LIBLO_CFLAGS = LIBLO_LIBS = -llo -lpthread Warning: this distribution contains XS files, but Module::Build is not configured with C_support at /usr/lib/perl5/vendor_perl/5.8.8/Module/Build/Base.pm line 1128. Checking prerequisites... Looks good Creating new 'Build' script for 'Net-LibLO' version '0.05' + perl Build lib/Net/LibLO/Address.pm -> blib/lib/Net/LibLO/Address.pm lib/Net/LibLO.pm -> blib/lib/Net/LibLO.pm lib/Net/LibLO/Bundle.pm -> blib/lib/Net/LibLO/Bundle.pm lib/Net/LibLO/Message.pm -> blib/lib/Net/LibLO/Message.pm lib/Net/LibLO.xs -> lib/Net/LibLO.c Module::Build is not configured with C_support at /usr/lib/perl5/vendor_perl/5.8.8/Module/Build/Base.pm line 3734. error: Bad exit status from /var/tmp/rpm-tmp.1227 (%build) ... thx for any hints Toni --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] My 2nd spec file; problems with install path using the build script
by Günter Dannoritzer 04 Jan '07

04 Jan '07

Hi, and Happy New Year, After successfully building my 1st RPM package, a Python module, I went on to build a package for a GUI application under openSuse 10.2. Everything seems to work fine up to the point when the installation process happens and I am getting first an error about wrong permissions and then it looks to me that some mix up with folders is happening. For more details I added the respective part of the build output below, followed by the spec file I am using. What is strange with the make ... install command below is, that the files are getting installed in /var/tmp/build-root/usr/bin. The DESTDIR option does not seem to be used. Only later this path is exported as RPM_BUILD_ROOT, but then the files cannot be found there, because the install happened to the different directory before? I am calling the build process as super user from the folder where the source and the spec files are located with the command: # build --rpms=$BUILD_RPMS/10_2 With $BUILD_RPMS/10_2 pointing to my 10.2 rpms. What am I doing wrong in the spec file that the binaries are getting installed into the wrong folder? Thanks for any help. Cheers, Guenter == part of build output ============================================= Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.32811 + umask 022 + cd /usr/src/packages/BUILD + cd gtkwave-3.0.18 + make DESTDIR=/var/tmp/gtkwave-3.0.18 install cd bin;\ install -d /usr/bin;\ install -m 0755 gtkwave /usr/bin/gtkwave;\ install -m 0755 twinwave /usr/bin/twinwave;\ [...] cd ../man;\ install -d /usr/share/man/man1;\ install -m 0644 gtkwave.1 /usr/share/man/man1/gtkwave.1;\ install -m 0644 twinwave.1 /usr/share/man/man1/twinwave.1;\ [...] + /bin/mv .gtkwaverc gtkwaverc.sample + /usr/lib/rpm/brp-lib64-linux sf(a)suse.de: if you find problems with this script, drop me a note + RPM_BUILD_ROOT=/var/tmp/gtkwave-3.0.18 + export RPM_BUILD_ROOT + test -x /usr/sbin/Check -a 0 = 0 -o -x /usr/sbin/Check -a '!' -z /var/tmp/gtkwave-3.0.18 + echo 'I call /usr/sbin/Check...' I call /usr/sbin/Check... + /usr/sbin/Check -rw-r--r-- 1 root root 786 Jan 1 22:56 /usr/share/man/man1/vztminer.1.gz -rw-r--r-- 1 root root 315 Jan 1 22:56 /usr/share/man/man1/mvl2lxt.1.gz -rw-r--r-- 1 root root 786 Jan 1 22:56 /usr/share/man/man1/lxt2miner.1.gz -rw-r--r-- 1 root root 971 Jan 1 22:56 /usr/share/man/man1/vcd2lxt.1.gz -rw-r--r-- 1 root root 394 Jan 1 22:56 /usr/share/man/man1/vzt2vcd.1.gz -rw-r--r-- 1 root root 677 Jan 1 22:56 /usr/share/man/man1/shmidcat.1.gz -rw-r--r-- 1 root root 334 Jan 1 22:56 /usr/share/man/man1/ghwdump.1.gz -rw-r--r-- 1 root root 935 Jan 1 22:56 /usr/share/man/man1/vcd2lxt2.1.gz -rw-r--r-- 1 root root 317 Jan 1 22:56 /usr/share/man/man1/mvl2vcd.1.gz -rw-r--r-- 1 root root 469 Jan 1 22:56 /usr/share/man/man1/tla2vcd.1.gz -rw-r--r-- 1 root root 857 Jan 1 22:56 /usr/share/man/man1/vertex.1.gz -rw-r--r-- 1 root root 540 Jan 1 22:56 /usr/share/man/man1/lxt2vcd.1.gz -rw-r--r-- 1 root root 316 Jan 1 22:56 /usr/share/man/man1/tex2vcd.1.gz -rw-r--r-- 1 root root 1136 Jan 1 22:56 /usr/share/man/man1/vcd2vzt.1.gz -rw-r--r-- 1 root root 669 Jan 1 22:56 /usr/share/man/man1/twinwave.1.gz -rw-r--r-- 1 root root 830 Jan 1 22:56 /usr/share/man/man1/rtlbrowse.1.gz -rw-r--r-- 1 root root 3245 Jan 1 22:56 /usr/share/man/man1/gtkwave.1.gz -rw-r--r-- 1 root root 4719 Jan 1 22:56 /usr/share/man/man5/gtkwaverc.5.gz Checking permissions and ownerships - using the permissions files /tmp/Check.perms.B20974 setting /usr/src/packages/SOURCES/ to root:root 1777. (wrong permissions 0755) setting /usr/src/packages/BUILD/ to root:root 1777. (wrong permissions 0755) setting /usr/src/packages/RPMS/ to root:root 1777. (wrong permissions 0755) setting /usr/src/packages/RPMS/i386/ to root:root 1777. (wrong permissions 0755) setting /usr/src/packages/RPMS/x86_64/ to root:root 1777. (wrong permissions 0755) setting /usr/src/packages/RPMS/noarch/ to root:root 1777. (wrong permissions 0755) setting /usr/src/packages/SPECS/ to root:root 1777. (wrong permissions 0755) setting /usr/src/packages/SRPMS/ to root:root 1777. (wrong permissions 0755) + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-symlink Processing files: gtkwave-3.0.18-1 error: File not found: /var/tmp/gtkwave-3.0.18/usr/bin/gtkwave error: File not found: /var/tmp/gtkwave-3.0.18/usr/bin/twinwave ==== spec file ===================================================== Below is the spec file I am using: %define name gtkwave %define version 3.0.18 %define release 1 %define Summary GTKWave Electronic Waveform Viewer Name: %{name} Version: %{version} Release: %{release} Summary: %{Summary} License: GPL+MIT Group: Productivity/Scientific/Electronics Source: %{name}-current.tar.gz URL: http://home.nc.rr.com/gtkwave/index.html Autoreqprov: on BuildRequires: gtk2-devel BuildRequires: libxml2-devel BuildRequires: flex zlib-devel bzip2 gperf BuildRoot: %{_tmppath}/%{name}-%{version} Packager: Guenter Dannoritzer <dannoritzer(a)web.de> %description GTKWave is a fully featured GTK+ based wave viewer for Unix and Win32 which reads LXT, LXT2, VZT, and GHW files as well as standard Verilog VCD/EVCD files and allows their viewing. %prep %setup -q %build %configure <<EOF 2 EOF %{__make} libdir=%libdir all %install %makeinstall %{__mv} .gtkwaverc gtkwaverc.sample %clean %{__rm} -rf %{buildroot} %post %postun %files %defattr(-, root, root) %doc *.TXT doc examples gtkwaverc.sample %{_bindir}/gtkwave %{_bindir}/twinwave [...] %{_mandir}/man1/gtkwave.1* %{_mandir}/man1/twinwave.1* --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 3

[opensuse-packaging] Something to consider to make a build rpm installable with zen?
by Günter Dannoritzer 03 Jan '07

03 Jan '07

Hi, I create a Python RPM file with the build script on my openSuse 10.2 system. Everything went fine and I can install the file with Yast and rpm -i, but when I try to install it with ZEN, the installation does not work. I use the Konquerer and try to open the file with the right-mouse menu "Install Software". The mouse switches to busy and I see an "Install Software" entry in the KDE panel, but after a few seconds it is gone, without any window opening that checks for dependencies, the way it usually does. Is there anything I need to consider to make the RPM ZEN installable? Thanks for the help. Cheers, Guenter --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0