openSUSE Packaging February 2008

packaging@lists.opensuse.org

43 participants
24 discussions

[opensuse-packaging] Use of icedtea in 11?

by Michal Vyskocil

Hi, I'm currently working on update of some java packages from OBS project Java:jpackage-1.7 to stable. So I'm also trying to build some of these packages with icedtea. Some of them should be builded (like adaptx) with small patches, some of them currently not (like hsqldb). But the switch to icedtea is not an automated process anymore, so if the autobuild team switches the compiler, majority of java packages will not be builded and needs to do some patches or revert back to the non free compiler. I can update a package and try to build it by icedtea, so I'm be able to switch the BuildRequire to java-1_7_0-icedtea-devel, if it works. The problem is, that the icedtea is only for i386 and a x86_64 available. On ppc or s390 we are using an IBM's compiler only. But a majority of a java packages is noarch, because a Java bytecode is architecture indepentent. I'm not sure, if I should use something like %ifarch %ix86 x86_64 BuildRequires: java-1_7_0-icedtea-devel %else BuildRequires: java-devel %endif in a spec file for noarch packages. May I try to build the most of java packages using icedtea? And if yes, how to do that? Use of the %ifarch in spec? Regards Michal Vyskocil --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 8 months

[opensuse-packaging] Yet Another Policy: No new packages in STABLE

by Stephan Kulow

Hi, Many people complain about Factory lacking dependencies on update. Most often this is due to new packages not yet being legally reviewed. So we discussed two policy chances (and will act on it after this email): - package splits / renames won't be reviewed in the future. For this clearly mark the split in the changelog. And do not branch packages that are not subpackages (this is _very_ important!). - new packages won't be checked into STABLE unless the base packagage (the name of the .src.rpm) is already reviewed (state production). Submit those packages to BETA and send a mail to suse-dist and only after your package was approved for distribution, submit it to STABLE. You can also submit it to STABLE too so you do not forget about it, but checkin will be delayed. I hope everyone understands the reasons. If not, check bug 365543. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 9 months

Re: [opensuse-packaging] [RFC Proposal] Distribution Branding

by radmanic＠novell.com

On Tuesday 26 February 2008 15:17:08 > Hallo. > > Here is a first draft of first part of proposal: creating of > branding-enabled packages. > > More should come later. > > > Proposal: Distribution Branding / Branding-Enabled Packages > > > Description of branding-enabled packages > > Branding-enabled packages provide its branding is a separate package. > > This technique is useful for: > > - Providing custom branding images. > - Providing custom default bookmarks. > > > Rules for packaging of branding enabled packages > > - Branding image should exist in a separate file. > - No custom branding images are added to the package. > > Package maintainer should split to two sub-packages - one with core > files (foo) and one with branding provided by upstream > (foo-branding-upstream). These packages are connected by branding > virtuals. Please keep in mind that a brand is somewhat like an identity or a signature and we should prevent misuse as good as possible. Branding can have legal implications, too. Therfore I propose the followiung amendments. - Branding packages must be mutually exclusive, but with the exception of the default "upstream" package. This should make sure that you cannot easily co-brand packages by adding your branding package to an existing one. This should prevent unauthorized co-branding - A brand package must contain a legal note on the authorized use of the package, its content and its distribution > Conventions > > > Package names > [...] > > Branding supplement > > Each branding package should supplement branding vendor. It allows to > choose correct branding package, if more branding packages are > available. Branding supplement symbol constist of "branding-" string and > symbolic name of the branding. Upstream branding symbolic name is > "upstream". > > > > Example: since we're talking about branding why not use #BRAND instead of #ART? > > Branding-enabled package: > > foo.spec: > Requires: foo-splash-300x400-art_foo_2_4 > Requires: foo-about-strip_middle-300x300 > > %package branding-upstream > Supplements: branding-upstream > #ART: foo-splash.png: png or jpg file, 300x400 pixels. Progress bar > #ART: will be displayed in lower 24 pixels. Image should include > #ART: package name "FOO" and version letters "2.4". > Provides: foo-splash-300x400-art_foo_2_4 > #ART: foo-info.png: Background of about dialog. Black names will > #ART: appear in the light stripe in the centre. > Provides: foo-about-strip_middle-300x300 regards -- Milisav Radmanic Engineering Manager Server Technologies SUSE LINUX Products GmbH Maxfeldstr. 5 90409 Nuernberg tel: +49 911 74053 0 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 9 months

[opensuse-packaging] Fatal and stricter rpmlint checks for Factory

by Dirk Mueller

Hi, I think that I'm finished with updating the set of rpmlint checks for 11.0. You can see the current set of failures in beta-i386 (the other architectures are not rebuilding). Please submit fixes for the new fails: executable-docs - documentation should not be executable. most of the time this comes from using "install" (which installs with executable permissions by default). use install -m 644 or the %doc macro. makefile-junk - generated Makefile's should not be in /usr/share library-without-ldconfig-postun - add %postun -p /sbin/ldconfig to the library package percent-in-* - most likely an unexpanded macro. e.g. %version is not defined before the Version: line in the spec file summary-too-long - the summary should be short. put the long stuff into %description invalid-pkgconfig-file - most likely contains an unexpanded macro. make sure that your AC_SUBST are correct and your autoreconf did not break it. file-contains-buildroot - files should never contain the buildroot. make sure that the $RPM_BUILD_ROOT is not used outside %install, and that stuff is not build/rebuild during %install. some too clever build systems try hardcoding paths, which breaks for buildroot installation. invalid-filepath-dependency - the list of paths that can be used in filerequires is fixed. if you violate, it will break installation. please report false positives to me before suppressing them! Thanks, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 9 months

Re: [opensuse-packaging] HAL: cleanup of deprecated keys/properties

by Danny Kukawka

On Donnerstag, 28. Februar 2008, Tambet Ingo wrote: > On Tue, Feb 26, 2008 at 1:19 PM, Danny Kukawka <dkukawka(a)suse.de> wrote: > > > with the next HAL package for STABLE/Factory (planed for Monday > > > 03.03.2008) some keys/properties get removed from HAL because they are > > > deprecated and marked since 12 months in the SPEC to get removed at > > > the end of this month. > > Hey, > > What are your plans with HAL version for opensuse 11? There are 4 > different FATE entries for NetworkManager support for 3G cards and for > it to work we need HAL's help from this commit (from February 15th): > > http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=9cece37fd82df82d24744d2 >1fce693ba4eefa447 That's already part of the test package from [1]. I can't tell you which version will be finaly in 11.0, that depends on the upstream release cycle. If there is no new release in time I do the same as with each openSUSE release: update our HAL package as as long as possible with git-snapshots. Danny [1] http://download.opensuse.org/repositories/home:/dkukawka:/hal-beta/ -- Danny Kukawka dkukawka(a)suse.de Mobile Devices SUSE LINUX a Novell Business Maxfeldstr. 5, D-90409 Nuernberg, Germany SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 9 months

[opensuse-packaging] dropping obsolete shared library packages?

by Stanislav Brabec

Hallo. In 11.0 we will have a new rules for shared library package names. It implies a question: What happens with old shared library packages after increment of soname. We cannot obsolete them (third party can still use them) and we should not not-obsolete them (as it will cause increasing number of orphaned packages in the system). Is there any solution for it? I can imagine several possibilities: Packaging level: Weak-Obsoletes as counterpart of Recommends: Delete, if it will not causes breakage. Zypp level: Handle packages named lib*[number] Advanced zypp level: Discriminate between explicitly required and dependent packages External script level: Find and delete all obsolete libraries ... -- 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, +49 911 740538747 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

12 years, 9 months

[opensuse-packaging] mozilla embedding news

by Wolfgang Rosenauer

Hi, (first sorry for the cross post but I wanted to make sure that everyone related has a chance to get that). openSUSE 11.0 is planned to have Firefox 3 and therefore we will also have Gecko 1.9 for embedding purposes. So far that has been done using mozilla-xulrunner181 which now got a first mozilla-xulrunner190 successor snapshot available for testing in the buildservice (mozilla:beta). Probably maw will start soon to bring that to factory. The test package does not replace older xulrunner versions yet but will reset the /usr/bin/xulrunner link to the new version. It shouldn't be a problem to install it in parallel on 10.2, 10.3 and factory. One note along the line: Gecko 1.9 won't run on distributions older than 10.2 because of gtk requirements. Relevant changes for projects embedding gecko are that the pkgconfig files changed their names. There are now: libxul-embedding-unstable.pc libxul-embedding.pc libxul-unstable.pc libxul.pc mozilla-gtkmozembed-embedding.pc mozilla-gtkmozembed.pc mozilla-js.pc mozilla-plugin.pc I'm encouraging anyone maintaining a depending package to play around with that and report issues to bugzilla's openSUSE 11.0 Firefox component. Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 9 months

[opensuse-packaging] [RFC Proposal] Distribution Branding (packages)

by Stanislav Brabec

Hallo. Here is a first draft of first part of proposal: creating of branding-enabled packages. More should come later. Proposal: Distribution Branding / Branding-Enabled Packages Description of branding-enabled packages Branding-enabled packages provide its branding is a separate package. This technique is useful for: - Providing custom branding images. - Providing custom default bookmarks. Rules for packaging of branding enabled packages - Branding image should exist in a separate file. - No custom branding images are added to the package. Package maintainer should split to two sub-packages - one with core files (foo) and one with branding provided by upstream (foo-branding-upstream). These packages are connected by branding virtuals. Conventions Package names All branding packages names should consist from three parts - package core name, string "-branding-" and the branding name. A special branding name is created by default: "upstream". This is a branding provided by upstream. Spec file comments Each file there should contain comment providing sufficient information for the artist. You can expect, that upstream branding will be available to the artist. Each line of these comment should start by "#ART: " string followed by these information: - Spec source file name (mandatory). Spec source package file name should be unique for the whole distribution. For example, if the target file name is /usr/share/foo/splash/image.png, source package file name should be foo-splash-image.png and it should be copied to the correct target in %install phase. - use case (mandatory, if it is not part of the file name itself, e. g. "about" - decoration of about dialog, "splash" - image displayed for a short time, when application is launching, "toolbar" - image in toolbar, "initial screen" - displayed when application is started before user starts to use it). - required art, if any (mandatory, if the image should contains program name letters, branch number, required logm comment should say, what exactly has to be included). - overlays, if any (mandatory, if the image is overlayed with any text in image, comment should say its size, color and position). - dependencies, if any (mandatory, if you can customize your look using another file, you must mention it). Examples: "Width of foo-img1.png must be the same as width of foo-bg.png." "You can define overlay text color, size and and position in splash.xml." - allowed file sizes (optional, if not present, artist has to follow upstream size). - allowed file formats (optional, if not present, artist has to follow upstream file format). - For branding of launcher icon it is preferred to create custom icon theme instead of branding. Branding virtual symbols Packager should create one virtual for each top-level file in the branding package (If the branding consists of an image, virtual should be relative to the image. If the branding consist from config or svg and related bitmap images, virtual should be relative to config or svg). Package maintainer is responsible for choosing of decent symbols. Requires and Provides should be no more strict than needed but must not be vague to allow bad branding. Use version based virtuals, if and only if the art itself contain version numbers. Examples: foo-splash-300x400 (splash is 300x400 in size) foo-splash-art_foo_2_4 (splash contains "FOO 2.4" letters art). Note to versioned branding symbols: If project uses per-branch branding, you cannot use versioned symbols (Provides: foo-splash = 2.4 will only complicate things, if it is designed to fit 2.4.1, using of foo-splash-art_2_4 is more appropriate). Branding supplement Each branding package should supplement branding vendor. It allows to choose correct branding package, if more branding packages are available. Branding supplement symbol constist of "branding-" string and symbolic name of the branding. Upstream branding symbolic name is "upstream". Example: Branding-enabled package: foo.spec: Requires: foo-splash-300x400-art_foo_2_4 Requires: foo-about-strip_middle-300x300 %package branding-upstream Supplements: branding-upstream #ART: foo-splash.png: png or jpg file, 300x400 pixels. Progress bar #ART: will be displayed in lower 24 pixels. Image should include #ART: package name "FOO" and version letters "2.4". Provides: foo-splash-300x400-art_foo_2_4 #ART: foo-info.png: Background of about dialog. Black names will #ART: appear in the light stripe in the centre. Provides: foo-about-strip_middle-300x300 Branding package: foo-branding-myvendor.spec: Supplements: branding-myvendor #ART: foo-splash.png: png or jpg file, 300x400 pixels. Progress bar #ART: will be displayed in lower 24 pixels. Image should include #ART: package name "FOO" and version letters "2.4". Provides: foo-splash-300x400-art_foo_2_4 #ART: foo-info.png: Background of about dialog. Black names will #ART: appear in the light stripe in the centre. Provides: foo-about-strip_middle-300x300 Branding virtual package or pattern provides resolvable branding-myvendor. -- 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, +49 911 740538747 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

12 years, 9 months

[opensuse-packaging] HAL: cleanup of deprecated keys/properties

by Danny Kukawka

Hi, with the next HAL package for STABLE/Factory (planed for Monday 03.03.2008) some keys/properties get removed from HAL because they are deprecated and marked since 12 months in the SPEC to get removed at the end of this month. The effected keys/properties are: * 2008-03-01: - info.bus --> replaced by info.subsystem - *.physical_device --> replaced by *.orginating_device * 2008-02-28: - smbios.system.manufacturer --> system.hardware.vendor - smbios.system.product --> system.hardware.product - smbios.system.version --> system.hardware.version - smbios.system.serial --> system.hardware.serial - smbios.system.uuid --> system.hardware.uuid - smbios.bios.vendor --> system.firmware.vendor - smbios.bios.version --> system.firmware.version - smbios.bios.release_date --> system.firmware.release_date - smbios.chassis.manufacturer --> system.chassis.manufacturer - smbios.chassis.type --> system.chassis.type - system.vendor --> system.hardware.vendor And please note, there are some keys planed to be removed at the end of March 2008. * 2008-03-21: - usb_device.speed_bcd (int) --> usb_device.speed (double) - usb_device.version_bcd (int) --> usb_device.version (double) Please check your packages for these keys (code and shipped fdi-files) and prepare them for the new HAL package. Danny -- Danny Kukawka dkukawka(a)suse.de Mobile Devices SUSE LINUX a Novell Business Maxfeldstr. 5, D-90409 Nuernberg, Germany SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 9 months

[opensuse-packaging] libraries renaming problems

by Petr Cerny

Hi, I'm not sure whether this hasn't been discussed here a while ago, yet I'm running into it more and more often lately: as libraries packages are renamed according to shlib policy, they do not provide older names, which makes some software uninstallable (especially with the latest libzypp based tools). Typical example of this is: libfoo -> libfoo1 which doesn't provide "libfoo" (only "libfoo1" as it's its name). When other package Requires: "libfoo", the package manager (and eventually the user) gets fooled and isn't able to install the desired package. Write .spec files like: Name: libfoo %define major 1 %define minor whatever Version: %{major}.%{minor} %package -n %{name}%{major} Provides: %{name} = %{version} should help. Best regards Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 9 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging February 2008