March 2007 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] GConf scritplets for dummies
by Stanislav Brabec 22 Mar '07

22 Mar '07

Hallo. Because many people asks, I am trying to explain problems with gconf scriptlets in detail. After installation of any package with gconf schemas, one needs to update gconf database. It's easy to do it. Much more complicated situation occurs, when you want to upgrade any application - you need to remove obsolete keys, but not remove the new ones. With older versions of RPM, it was not possible at all, so we installed schemas and kept them forever. Now it is possible, so I created a new implementation. It is be available in openSUSE 10.3 and in GNOME:UNSTABLE. As a bonus, macros also create schemas part of file list for you - it could not happen, that you forget to install any schemas file (which can cause an application crash). Here is a simple howto. It also contains some common tricks you will need in packages: Preamble (i. e. initial set of lines; put it as last command, automatic spec formatters used by SuSE are not able to read lines after it): %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 You don't have to list schemas files in the file list, it is done automatically for you. 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/ --------------------------------------------------------------------- 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] semi-automatic generation of BuildRequires by pkg-config
by Stanislav Brabec 22 Mar '07

22 Mar '07

Hallo. Here is my attempt to help with creating BuildRequires semi-automatically. It now works for pkg-config checks. It is an initial version, which does not have any automation support. It may move major part of BuildRequires into auto-generated part. It works nice on my tests. Warning: It does not check for disabled features. INSTALL: Install script-pkg-config somewhere outside your $PATH. Set PKG_WRAP_DIR in pkg-buildrequires-wrap to your directory, where pkg-config resides. HOWTO: cd to unpacked sources pkg-buildrequires-wrap ./configure --enable-foo ... It will create pkg-buildrequires-wrap.log cd anywhere pkg-create-buildrequires unpacked_sources_directory_where_you_run_pkg-buildrequires-wrap It will analyze pkg-buildrequires-wrap.log and create pkg-buildrequires.log pkg-create-buildrequires foo.spec It will pick pkg-buildrequires-wrap.log and update foo.spec -- 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/

1 0

[opensuse-packaging] Trouble with the neededforbuild macro
by Jules Colding 22 Mar '07

22 Mar '07

Hi, I'm trying to build an evolution-brutus (e-b) RPM in OpenSUSE 10.2. A few additional packages are required for e-b to build in OpenSUSE as opposed to Fedora for which the spec file is originally developed. The additional packages are: mDNSResponder-lib lsb gnome-common libidl-devel I've experimented with the neededforbuild macro instead of adding additional BuildRequires statements. This unfortunately makes 'build' complain about failed build dependencies. In other words - it works if I add additional BuildRequires statements: BuildRequires: mDNSResponder-lib BuildRequires: lsb BuildRequires: gnome-common BuildRequires: libidl-devel But it does not work if I use the neededforbuild macro like this: # neededforbuild mDNSResponder-lib lsb gnome-common libidl-devel Any ideas? Thanks, jules --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

7 8

[opensuse-packaging] How do I get debuginfo rpms build?
by Jules Colding 22 Mar '07

22 Mar '07

Hi, My troubles with the 'build' script are now resolved, but I'm wondering how I makes it create the debuginfo RPM. Is there a special option that I need to use or a trick in the spec file? My spec is here: http://www.omesc.com/content/downloads/dist/OpenSUSE%2010.2/SOURCES/evoluti… Thanks, jules --------------------------------------------------------------------- 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] "knx" package should be removed - due to unmaintainence.
by Alexey Eremenko 21 Mar '07

21 Mar '07

Hi all ! There is a very old NX-client package made by OSS community and never updated. knx. The problem is that it is based on NX v1 protocol, while current NX implementation is v2 (FreeNX 0.50+ is v2 NX server) of NX protocol. Those are not fully compatible, and therefore it makes errors and doesn't always connects to the server. In short, My recommendation: remove "knx" client (unmaintained), and add Proprietary NoMachine's NX Client to the non-OSS CD. (from www.nomachine.com/download ) I know this is a hard decision to move from OSS to Proprietary software, but in this case a needed one, unless someone agrees to maintain the OSS client. LfL includes a full article, written by me, about NX technology. -- -Alexey Eremenko "Technologov" --------------------------------------------------------------------- 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] problematic new path naming structure
by Jurzitza, Dieter 20 Mar '07

20 Mar '07

Dear Robert, dear listmembers, > > Call the directory /lib/modules/persistent from the very > begin. Maybe > > one would like to use persistent-default / persistent-bigsmp. > > This does not work because it does not allow installation of > multiple kernels with different ABIs. well, how would this work right now? The packages provided binary are provided for one single kernel, probably for default / bigsmp, that's about it. The question is: why make the majority of people using a single kernel configuration suffer from a somewhat exotic concept of people using different kernels in parallel (rumor on the list ;-))? In my understanding the SuSE concept is straightforward and monolithic to a certain point: you get a kernel with the distribution, you use it, you may upgrade "in line", but just try to upgrade from i.e. 2.6.11 to 2.6.13, a decent part of things like the automount functionality (among other discrepancies) is gone because things do not match any more. If you want to do what you suggest you will have to rebuild all the kernel module extra packages from scratch for the new kernel anyway, no improvement here. The current concept does not work for this either. I can only support what Herbert Graeber said. But as initially stated, these are just my 2 cents here :-). We won't solve the issue here. Take care Dieter -- ________________________________________________ HARMAN BECKER AUTOMOTIVE SYSTEMS Dr.-Ing. Dieter Jurzitza Manager Hardware Systems System Development Industriegebiet Ittersbach Becker-Göring Str. 16 D-76307 Karlsbad / Germany Phone: +49 (0)7248 71-1577 Mobile: +49 0151 - 16 339 017 Fax: +49 (0)7248 71-1216 eMail: DJurzitza(a)harmanbecker.com Internet: http://www.becker.de > -----Ursprüngliche Nachricht----- > Von: Robert Schiele [mailto:rschiele@gmail.com] > Gesendet: Dienstag, 20. März 2007 15:44 > An: Jurzitza, Dieter > Cc: opensuse-packaging(a)opensuse.org > Betreff: Re: [opensuse-packaging] problematic new path naming > structure > > > On Tue, Mar 20, 2007 at 02:03:48PM +0100, Jurzitza, Dieter wrote: > > Though I agree that the naming I coose is probably not optimal as > > these modules are not "persistent" by themselfes, the > persistence will > > last as long as the ABI compatibility will last. But this in turn > > gives persistence and therefore I still think to use > "persistence" in > > the name is not the worst choice in this regard. > > This is not about the name of the directory but about whether > it does work or not. > > > Therefore I do not agree entirely with Roberts arguments. These > > modules belong to 2.6.18.2 in the same way as they belong > to 2.6.18.8 > > or any other 2.6.X kernel that keeps this part of the ABI constant. > > From what I have learned they are not initially related to 2.6.18.2. > > I don't think that it is important whether you agree with me > or not as long as you propose to replace a system that works > with another system that does not work. > > > IMHO it is only bad to refer to names of components that > are not used > > any more in your system (what is true in the very moment you do > > upgrade now). Spoken from experience I can hardly remember a SUSE > > distribution that did not upgrade the kernel at some point > in time. So > > I'd say this is something that should be expected. > > > > In a "generic" sense it would be best to start with soft-linked > > modules from the very begin of a distribution, what is in > tune with my > > statement. > > > > And one could remove the reference to the individual kernel > entirely: > > Call the directory /lib/modules/persistent from the very > begin. Maybe > > one would like to use persistent-default / persistent-bigsmp. > > This does not work because it does not allow installation of > multiple kernels with different ABIs. > > Robert > > -- > Robert Schiele > Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com > > "Quidquid latine dictum sit, altum sonatur." > ******************************************* Harman Becker Automotive Systems GmbH Geschaeftsfuehrung: Dr. Peter Geiselhart - Michael Mauser - William S. Palin - Edwin Summers - Regis Baudot Sitz der Gesellschaft: Karlsbad - Registergericht: Mannheim HRB 361395 ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ******************************************* --------------------------------------------------------------------- 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] problematic new path naming structure
by Jurzitza, Dieter 20 Mar '07

20 Mar '07

Dear listmembers, after a longer absence from upgrading I decided to test openSUSE 10.2 after it had had been released. Performing the latest kernel update an IMHO unlucky modification in the name distribution popped up that I would like to discuss. The directory /lib/modules/2.6.18.2-34 is remaining after kernel update to 2.6.18.8 and a part of the modules are linked into a corresponding path within 2.6.18.8 from there. IMHO this is a very ugly way to do things. If there are modules that are *not* kernel specific the corresponding directory should be called different. Why keep a reference to a kernel that is actually no reference to this specific kernel? IMHO this directory should be named in such a way that it is easy to understand that the modules contained within it are to a certain degree version independent, such as /lib/modules/2.6.18-persistent or whatsoever. Keeping the old name is a poor and irritating choice. Just to point out my 2 cents here ... Take care Dieter Jurzitza -- ________________________________________________ HARMAN BECKER AUTOMOTIVE SYSTEMS Dr.-Ing. Dieter Jurzitza Manager Hardware Systems System Development Industriegebiet Ittersbach Becker-Göring Str. 16 D-76307 Karlsbad / Germany Phone: +49 (0)7248 71-1577 Mobile: +49 0151 - 16 339 017 Fax: +49 (0)7248 71-1216 eMail: DJurzitza(a)harmanbecker.com Internet: http://www.becker.de ******************************************* Harman Becker Automotive Systems GmbH Geschaeftsfuehrung: Dr. Peter Geiselhart - Michael Mauser - William S. Palin - Edwin Summers - Regis Baudot Sitz der Gesellschaft: Karlsbad - Registergericht: Mannheim HRB 361395 ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ******************************************* --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 4

AW: [opensuse-packaging] problematic new path naming structure
by Jurzitza, Dieter 20 Mar '07

20 Mar '07

Dear Robert, dear listmembers, AFAIK the modules that are used for this are packaged as binaries in rpm-containers (i. e. like slmodem or wlan - modules). If the ABI would change, those packages would have to be upgraded anyway and SUSE would be urged to provide the corresponding packages in conjunction with such a major kernel upgrade. Though I agree that the naming I coose is probably not optimal as these modules are not "persistent" by themselfes, the persistence will last as long as the ABI compatibility will last. But this in turn gives persistence and therefore I still think to use "persistence" in the name is not the worst choice in this regard. Therefore I do not agree entirely with Roberts arguments. These modules belong to 2.6.18.2 in the same way as they belong to 2.6.18.8 or any other 2.6.X kernel that keeps this part of the ABI constant. From what I have learned they are not initially related to 2.6.18.2. IMHO it is only bad to refer to names of components that are not used any more in your system (what is true in the very moment you do upgrade now). Spoken from experience I can hardly remember a SUSE distribution that did not upgrade the kernel at some point in time. So I'd say this is something that should be expected. In a "generic" sense it would be best to start with soft-linked modules from the very begin of a distribution, what is in tune with my statement. And one could remove the reference to the individual kernel entirely: Call the directory /lib/modules/persistent from the very begin. Maybe one would like to use persistent-default / persistent-bigsmp. Put in all module-binaries that stem from non-kernel-rpms (i.e. wlan<something>.rpm or slmodem<something>.rpm). Start with linking those into the appropriate kernel-module directories from the very begin. Whenever the abi changes, one must change / upgrade the packages anyway - there is no harm in this case, the package manager and the dependency rules have to prevent from errors here. The container of those packages would never refer to a kernel that came out of use. Take care Dieter Jurzitza -- ________________________________________________ HARMAN BECKER AUTOMOTIVE SYSTEMS Dr.-Ing. Dieter Jurzitza Manager Hardware Systems System Development Industriegebiet Ittersbach Becker-Göring Str. 16 D-76307 Karlsbad / Germany Phone: +49 (0)7248 71-1577 Mobile: +49 0151 - 16 339 017 Fax: +49 (0)7248 71-1216 eMail: DJurzitza(a)harmanbecker.com Internet: http://www.becker.de > -----Ursprüngliche Nachricht----- > Von: Robert Schiele [mailto:rschiele@gmail.com] > Gesendet: Dienstag, 20. März 2007 09:40 > An: Jurzitza, Dieter > Cc: opensuse-packaging(a)opensuse.org > Betreff: Re: [opensuse-packaging] problematic new path naming > structure ***** > Feel free to suggest a better scheme but only suggest a > scheme that actually does _work_. ***** ******************************************* Harman Becker Automotive Systems GmbH Geschaeftsfuehrung: Dr. Peter Geiselhart - Michael Mauser - William S. Palin - Edwin Summers - Regis Baudot Sitz der Gesellschaft: Karlsbad - Registergericht: Mannheim HRB 361395 ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ******************************************* --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 2

[opensuse-packaging] Proposal: Any "rm" in .spec %install must be commented
by Stanislav Brabec 16 Mar '07

16 Mar '07

Hallo. I have just notified, that many people "fix" (i. e. break) their packages to pass QA checks by removing required files instead of fixing them, i. e. removing .desktop files instead of installing icon or fixing Categories, removing gconf schemas instead of correct installation. So I propose: Each removal in %install phase must be correctly commented (i. e. why these files are obsolete or why they are installed by mistake), otherwise package will not be checked-in. Please discuss on opensuse-packaging(a)opensuse.org See also https://bugzilla.novell.com/show_bug.cgi?id=254868 -- 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

10 26

[opensuse-packaging] RPM and Perl
by Bernhard Graf 16 Mar '07

16 Mar '07

Hello, I'm a first time poster to this list and hope it is the appropriate forum for this subject. I wanted to know the best way to cope with RPM and Perl modules. The Perl distribution (Perl 5.8.8 atm) comes with a core of standard modules. These are also part of the perl.rpm that comes with SuSE. Meanwhile for most of the Perl core modules there are newer versions available on CPAN, e.g. CGI.pm. Other (non-core) modules require these newer version. My question is: what is the best - or recommended - way to update Perl modules of the core? Of course I can simply invoke the cpan script and install them in no time at all, but then RPM's dependency mechanism would never know about this. This in turn means I cannot build an RPM (with correct requirements) for a non-core module that requires a newer module version from the core modules Any ideas welcome. -- Bernhard Graf <opensuse(a)augensalat.de> --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0