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
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
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
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
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
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
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
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
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
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