February 2008

[opensuse-packaging] Use of icedtea in 11?
by Michal Vyskocil 08 Mar '08

08 Mar '08

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 … [View More]

4 5

[opensuse-packaging] Yet Another Policy: No new packages in STABLE
by Stephan Kulow 06 Mar '08

06 Mar '08

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 … [View More]

4 4

Re: [opensuse-packaging] [RFC Proposal] Distribution Branding
by radmanic＠novell.com 29 Feb '08

29 Feb '08

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. > - … [View More]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 [View Less]

2 3

[opensuse-packaging] Fatal and stricter rpmlint checks for Factory
by Dirk Mueller 28 Feb '08

28 Feb '08

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 … [View More]

1 0

Re: [opensuse-packaging] HAL: cleanup of deprecated keys/properties
by Danny Kukawka 28 Feb '08

28 Feb '08

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 … [View More]

1 0

[opensuse-packaging] dropping obsolete shared library packages?
by Stanislav Brabec 27 Feb '08

27 Feb '08

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 … [View More]

7 12

[opensuse-packaging] mozilla embedding news
by Wolfgang Rosenauer 27 Feb '08

27 Feb '08

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 … [View More]

1 0

[opensuse-packaging] [RFC Proposal] Distribution Branding (packages)
by Stanislav Brabec 27 Feb '08

27 Feb '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 … [View More]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 [View Less]

8 21

[opensuse-packaging] HAL: cleanup of deprecated keys/properties
by Danny Kukawka 26 Feb '08

26 Feb '08

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 --> … [View More]

1 1

[opensuse-packaging] libraries renaming problems
by Petr Cerny 25 Feb '08

25 Feb '08

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 … [View More]

7 12

Main

Development

Information

Community

Social Media

Other

openSUSE Packaging