- openSUSE Packaging

[opensuse-packaging] page not found
by Marc Collin 03 Jun '06

03 Jun '06

hi i copied suse dvd on my computer to be able to use build. it copied to /opt/dvd_suse in /opt/dvd_suse/suse/x86_64 i have libdvdread-0.9.4-160.x86_64.rpm this rpm don't seem to be on the dvd..... i take it on a suse ftp libdvdread-devel-0.9.4-160.x86_64.rpm when i do: build --rpms /opt/dvd_suse expanding package dependencies... expansion error nothing provides libdvdread-devel does i need to change something than build see the rpm i add (libdvdread-devel-0.9.4-160.x86_64.rpm) thank ---------- Marc Collin http://www.laboiteaprog.com --------------------------------------------------------------------- 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] KDE:KDE3: kdelibs3-3.5.3 depends on libexpat.so.1 (on 10.0)
by Pascal Bleser 02 Jun '06

02 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Not sure where to send this, sorry for cross-posting. The kdelibs3-3.5.3 package in KDE:KDE3 for SL 10.0 requires libexpat.so.1, but there's no package that provides libexpat.so.1 for 10.0 (excapt [1] but that's not really an option). [1] http://www.suse.de/~mhopf/xgl/ How to handle KDE:KDE3 bugs ? bugzilla ? one of these lists ? Could someone have a look at it please ? thanks :) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEf3Ekr3NMWliFcXcRAnwSAKCJAeLZi4O+DZ52Y/0ipSKfzlNjYwCgt5I5 sigVAyR5jUhRpPC9MEgEAR0= =x8cA -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging-help(a)opensuse.org

2 1

[opensuse-packaging] XML Project in the Build Service
by Karl Eichwalder 02 Jun '06

02 Jun '06

I started the XML Project (http://build.opensuse.org/project/show?project=XML) and I will happily accept co-maintainers who are either experienced in packaging issues or the XML technologies. Also feel free to propose new tools and make use of http://en.opensuse.org/SGML_and_XML . -- Karl Eichwalder R&D / Documentation SUSE Linux Products GmbH Key fingerprint = B2A3 AF2F CFC8 40B1 67EA 475A 5903 A21B 06EB 882E --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging-help(a)opensuse.org

2 2

ladspa
by Oliver Bengs 30 May '06

30 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have compailed MusE for SuSE 10.1. Compile works fine but at start i become the follow error message: Unabel to find ladspa_descriptor() function in plugin library file "/usr/lib/ladspa/sine.so":/usr/lub/sine.so: undefined symbol: ladspa_descriptor. I think OK a problem with ladspa. I load the ladspa-1.12.20050216-7.src.rpm and tried to recompile it. ladspa has libselinux as BuildRequire, there is no libselinux in 10.1? Then i removed libselinux as BuildRequire. Now the compile breaks with c++ -O2 -g -m32 -march=i586 -mtune=i686 -fmessage-length=0 - -D_FORTIFY_SOURCE=2 - fPIC -I. -o plugins/sine.o -c plugins/sine.cpp plugins/sine.cpp: In constructor ‘StartupShutdownHandler::StartupShutdownHandler ()’: plugins/sine.cpp:266: error: ‘instantiateSineOscillator’ was not declared in this scope plugins/sine.cpp:268: error: ‘connectPortToSineOscillator’ was not declared in this scope plugins/sine.cpp:270: error: ‘activateSineOscillator’ was not declared in this scope plugins/sine.cpp:278: error: ‘cleanupSineOscillator’ was not declared in this scope plugins/sine.cpp:291: error: ‘runSineOscillator_FreqAudio_AmpAudio’ was not declared in this scope plugins/sine.cpp:303: error: ‘runSineOscillator_FreqAudio_AmpCtrl’ was not declared in this scope plugins/sine.cpp:315: error: ‘runSineOscillator_FreqCtrl_AmpAudio’ was not declared in this scope plugins/sine.cpp:327: error: ‘runSineOscillator_FreqCtrl_AmpCtrl’ was not declared in this scope Anyone an idea Why i can't rebuild it? Oliver Bengs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEeyTNj/glEAdJRAMRAgs7AJ9pqXGn4rIwoGMVl4uyperjYh4SzwCggO8Q FSL9JPMu+c7YBMyX+7Ze++0= =DmFP -----END PGP SIGNATURE-----

2 1

Howto install IBM Java2 sdk package
by doug arro 26 May '06

26 May '06

Hi, I am new to SUSE. My system is OpenSUSE 10.1 The YaST tool only shows the j2sdk packages from SUN, but none from IBM. Can I download the rpm from the IBM website and install it with YaST? Just wondering what is the best way to install 3rd party rpms like this in OpenSUSE. Doug __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

makefile impact specfile?
by Marc Collin 24 May '06

24 May '06

hi i would like to know if the makefile can have an impact on the specfile? i create a specfile step by step BuildRoot: %{_tmppath}/%{name}-%{version} %description spca5xx video for linux (v4l) driver, providing support for webcams and digital cameras based on the spca5xx range of chips manufactured by SunPlus Sonix Z-star Vimicro Conexant Etoms Transvision Mars-Semi Pixart. %prep %setup %build make build --rpms /opt/dvd_suse return /bin/chgrp -Rhf root . + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.56470 + umask 022 + cd /usr/src/packages/BUILD + /bin/rm -rf /var/tmp/spca5xx-20060501 ++ dirname /var/tmp/spca5xx-20060501 + /bin/mkdir -p /var/tmp + /bin/mkdir /var/tmp/spca5xx-20060501 + cd spca5xx-20060501 + make Building SPCA5XX driver for 2.5/2.6 kernel. Remember: you must have read/write access to your kernel source tree. make -C /lib/modules/`uname -r`/build SUBDIRS=/usr/src/packages/BUILD/spca5xx-20060501 CC=cc modules make: *** /lib/modules/2.6.16.13-4-default/build: No such file or directory. Stop. make: *** [default] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.56470 (%build) not sure but with this message, the build don't seem to take the right folder.... thanks

4 5

Patch name and comments proposal
by Pavel Nemec 22 May '06

22 May '06

We are working on patch naming for SUSE Package Conventions (http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc.html) This is proposal and comments from community are welcome. Reasons/ motivations: why we need this: ------------------------------------------------------- - backup maintainers - team working on bug fixing -> unified way of patching - tracking changes in patch, tracking mainstream patches 1. Patch Name ----------------------- 1.1 Suffix ------------ We need to choose unified suffix for patch name. Commonly used suffixes are: "patch, diff, dif" Suffix "Patch" and "Diff" are most commonly used. There is no rational reason why one "Patch" or "Diff" should NOT be used. "Diff" suffix is associated with shared mime info Proposal: - use "patch" suffix, do not rename old patches. Do not use "dif" suffix any more. 1.2 Naming --------------- Name of package should be very intuitive and should tell maintainer what this patch actually fix. Name of patch should consist of: Name, Number, Mnemonic hint 1.2.1 Name --------------- There is two way for choose patch name, use package name, or use source name. There are packages with more than one source in package. Proposal: - use name of source which patch is apply to. Patch should not fix files from different source. - if is not possible use name of source, use name of package instead. 1.2.2 Number ------------------ Number as version of source or package is heavily used in patch name. This could confuse new maintainer because it suggest that patch is version dependent. If this package is not version dependent and package is updated to new version, all patch had to be updated. In SUSE, there are many packages which contains patch, which are not sent to upstream, because they fix SUSE specific problems. Proposal: - use no number at all for patch which are not meant to be send in upstream (SUSE specific, temporary distribution dependent fix ....) - use number for patch which are only for this version of package (source), this patch should be sent to upstream. This number should be changed when updating to new version if we still expect this patch to be accepted by upstream. If no, number should be removed from this patch. 1.2.3 Mnemonic hint --------------------------- Mnemonic hint should tell (together with changelog) what this patch fix. There are only common hints how to do useful hints. Proposal: - use '-' for separate section in name and '_' for separating words e.g.: gcc-really_useful.patch enlightenment-gcc-error.patch lftp-compat-mode.patch graphviz-fix_swig_template.patch - if fixed problem could not be easily hinted by short name, you can use bugzilla number, or security bug reference ID (like CVE, PMASA). We could consider creating table of commonly used hints. e.g.: CVE-2005-3353.patch PMASA-2005-6.patch php-5.1.2-phpbug-36208.patch - there are patch which fix problem which is caused by another part of system ( broken library, autobuild....). Patch name should reflex this. We propose to use buildfix/temporaryfix/runfix for such patch. This patch should be removed as soon as possible (probably when updating to new version) buildfix - if this package could be builded, this patch could be safely removed. runfix - if this package could be runed without this patch, this patch could be safely removed. temporaryfix - all other temporary fix. 2. Changelog ------------------ All changes in package (adding/removing patch, changing spec file ...) should be mentioned in changelog. From name of patch changelog and comments in patch should be clear what change was made. Proposal: - mention add or remove patch in changelog e.g. [ ...] - added patch -gcc-error.patch - use number of bug from bugzilla., Name of bugzilla should be used if it is not obvious e.g. fixed gcc error [#32423] fixed gcc error, openoffice [#3224324] - use reference to security ID in changelog e.g. - fixed completely broken SplTempFileObject [php#37257] - if fix is more complicated, additional info in header of patch file should be present! - additional info in patch should be present also in patch which will be presented in package for long time (program is not developed any longer...) 3. Patch in specfile ------------------------- Main problem with patch in specfile is numbering. When patches are added they have increasing number. Php example: Patch1: php5-config.patch Patch2: php5-phpize.patch Patch3: php5-apache_sapi_install.patch Patch4: php5-php-config.patch Patch5: php-%{version}-include_path.patch [ ... snip, there are about 51 patches] When patch is removed, there are hole in specfile, which could look ugly. But renumbering is time consuming. There is possible to use unused number, but adding position in spec file should be preserved. Example Patch1: php5-config.patch Patch3: php5-apache_sapi_install.patch Patch4: php5-php-config.patch Patch5: php-%{version}-include_path.patch Patch2: php5-new.patch When patch is commented in spec file and not deleted, there should be comment, explaining this. e.g. # FIXME: This patch should be backported. #%patch2 # Uncomment this patch, if automake fails. #%patch3 Comment should be also used, if patch is used differently than normal. e.g. (blender) Patch1: po.patch Patch2: blender-home-to-datadir.patch # patch is applied only on x86-64 Patch5: Scons.patch [...] 4. Common advise ------------------------- - when fixing package, try to keep style convention set by author of this package (if it is still any) e.g. some one write bugzilla number as "#234345", [#33453453], (#2342342) - do not overwrite changelogs - preserve time stamps of file you do not modify. -- Pavel Nemec package-maintainer http://en.opensuse.org/Czech_Packagers_Team --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: pnemec(a)suse.cz Drahobejlova 27 tel:+420 2 9654 2373 190 00 Praha 9 fax:+420 2 9654 2374 Ceska republika http://www.suse.cz

5 6

Re: Create spec file
by Marc Collin 22 May '06

22 May '06

> Hi, > > On Monday, May 22, 2006 at 01:44:39, Marc Collin wrote: > >> i begin to create rpm for suse >> >> configure: error: IMWheel depends on the X11 libraries! >> >> i don't understand why it don't get the X11 librairies, i copied all the >> dvd in /opt/dvd_suse > > You are probably missing BuildRequires to xorg-x11-libs and > xorg-x11-devel > > Henne > ya know that compile i read this tutorial http://www-128.ibm.com/developerworks/library/l-rpm1/ i get: build --rpms /opt/dvd_suse error: Installed (but unpackaged) file(s) found: /usr/X11/bin/imwheel /usr/local/man/man1/imwheel.1.gz i tried to add in the spec file: %config(noreplace) /etc/imwheelrc /usr/X11R6/bin/imwheel %attr(0755, root, root) %{prefix}/bin/imwheel %{prefix}/man/man1/imwheel.1x.bz2 but i get RPM build errors: File not found: /var/tmp/imwheel-1.0.0pre12-build/etc/imwheelrc File not found: /var/tmp/imwheel-1.0.0pre12-build/usr/X11R6/bin/imwheel linux64:/usr/src/packages/SOURCES/imwheel # build --rpms /opt/dvd_suse logging output to /var/tmp/build-root/.build.log... ---- www.laboiteaprog.com

3 10

create spec file
by Marc Collin 22 May '06

22 May '06

hi i begin to create rpm for suse i installed build i don't find a good tutorial about specfile in my spec file i have: %define prefix /usr/X11 ... ... %prep rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT %setup %build ./configure make all %install mkdir -p $RPM_BUILD_ROOT%{prefix}/bin $RPM_BUILD_ROOT%{prefix}/man/man1 $RPM_BUILD_ROOT%{prefix}/etc /usr/bin/install -c -d -o root -g root -m 0755 $RPM_BUILD_ROOT%{prefix}/bin /usr/bin/install -c -o root -g root -m 0755 imwheel $RPM_BUILD_ROOT%{prefix}/bin/imwheel /usr/bin/install -c -d -o root -g root -m 0755 $RPM_BUILD_ROOT%{prefix}/man/man1 /usr/bin/install -c -o root -g root -m 0644 imwheel.1 $RPM_BUILD_ROOT%{prefix}/man/man1/imwheel.1x %{bz2} -9 $RPM_BUILD_ROOT%{prefix}/man/man1/imwheel.1x /usr/bin/install -c -d -o root -g root -m 0755 $RPM_BUILD_ROOT/%{cfg} /usr/bin/install -c -o root -g root -m 0644 imwheelrc $RPM_BUILD_ROOT/%{cfg}/imwheelrc when i do: /usr/src/packages/SOURCES/imwheel # build --rpms /opt/dvd_suse/ i get: hecking where the pid file goes... /tmp checking if we suid imwheel at install... no checking if we use the included getopts... no checking if we build mdetect... no checking if we build mdump... no checking if we build extras... no checking for gpm-1.19.3/gpm.c... no checking if we build gpm-imwheel... no checking for X... no checking for XCreateWindow in -lX11... no configure: error: IMWheel depends on the X11 libraries! linux64:/usr/src/packages/SOURCES/imwheel # error: Bad exit status from /var/tmp/rpm-tmp.84858 (%build) i don't understand why it don't get the X11 librairies, i copied all the dvd in /opt/dvd_suse if i use only the source ./configure make all work without problem thank -- www.laboiteaprog.com

2 1

dropping and renaming plan for GNOME1 (GTK1)
by Stanislav Brabec 19 May '06

19 May '06

Hallo. After four years after GNOME2/GTK2 release, the last "killer" application - gnucash, will be finally ported to GNOME2. So we are ready to drop GNOME1 from SuSE Linux. There is a proposal of the dropping plan: Phase 1 (August 2003): Drop everything not needed for gnucash 1, rename foo2 to foo, if applicable. Status: Done Phase 2 (May 2006): Drop everything except core GNOME1. Status: Done Packages for dropping: bonobo control-center gconf gnome-print gnome-spell gnome-vfs gtkhtml oaf Affected packages: none Phase 3 (May 2006): Think about robust naming scheme of packages, where can coexist in more major versions without confusion and often renaming. See below for discussion summary. Phase 4 (near future): Drop core GNOME1. Status: Little work needed Packages for dropping: libglade libxml orbit gnome-libs Affected packages: loki_setup, loki_update (installer) Proposed solution: http://www.icculus.org/loki_setup/ frontline (frontend for autotrace) Proposed solution: drop coriander (IEEE-1394 Digital Camera Controller) Proposed solution: Replace, drop or port soundtracker (sound tracker) Proposed solution: Replace, drop or port bombermaze (game) Proposed solution: Replace or drop gdk-pixbuf (image library) Proposed solution: do not package GNOME1 extension perl-Gtk-Perl (perl bindings) Proposed solution: do not package GNOME1 bindings unixODBC-gui-gtk Proposed solution: do not package GNOME1 interface and popular third party ogle (DVD player) Phase 5 (sometimes in future): Drop GTK1. Status: A lot of work needed Packages for dropping: gtk, glib, gdk-pixbuf, gtk-engines imlib Affected packages: ami gal gau xmms-jack evms-gui pcsx surf xmms xzgv xmms-gnome2 winetools flac-xmms fvwm2 gqcam smpeg-gtv swami bidwatcher loki_uninstall powertweak-gtk python-xmms wmakerconf Xdialog manedit perl-Xmms WindowMaker-applets sylpheed-claws amarok-xmms ardour gbuffy gentoo squaroid gtkzip nicolatter glchess kanji-lookup pcpmon perl-Gtk-Perl alsaplayer TeX-Guy unison procmeter usbview xdelta xmorph sipset xlogmastergoom2k4 xmms-plugins xarchon and popular third party mplayer Proposed solution: Use gtk1-compat-devel (and extend it to cover more), drop, port, turn different frontend instead of GTK1, if available. Naming schemas: Desired properties: - only rename if absolutely not avoidable - use same name as upstream if possible - we can only have one package with an identical name Possible naming schemes: 1) mainline stable without number, old branches with number. Advantage: - use same name as upstream if possible for the head version Problems: - BuildRequires must not use package name but some feature virtual - The moment, when devel branch becomes stable, needs ugly renames - Will cause undefined RPM dependencies Result: Probably not acceptable 2) keep old branch as is and add suffix for new one Advantage: - simple Problems: - having branch number for half of packages is irritating. - additional rename is also not comfortable Result: Confusing use of branch numbers 3) keep old branch as is and add suffix for new one. Rename back, when old branch is dropped (It's the actually used approach.) Advantage: - simple Problem: - having branch number for half of packages is irritating. - many package renames Result: Current solution, ugly, partially confusing use of branch numbers 4) all branches with numbers deduced from, say .pc files names (maybe with dots and trailing zeroes removed). Advantage: - never rename package which does not change API Problems: - packages has names different from upstream - most packages will have untrivial name and version, e. g. gnome-vfs-2.0-2.12.3 (resp. gnome-vfs2-2.12.3) and also gtkmm24-2.8.2. Result: Needs to think twice before using this scheme. 5) ??? -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SuSE CR, s. r. o. e-mail: sbrabec(a)suse.cz Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9 fax: +420 296 542 374 Czech Republic http://www.suse.cz/

1 0