Hello all,
openSUSE 13.1 Beta will be released next week, on
Thursday 19 September 2013.
Please submit your packages before Friday afternoon (UTC time) to make
sure they will get included in this release. Leaf packages submitted
during the week-end might also get accepted on Monday.
For a quick overview of the openSUSE Roadmap, please see:
http://en.opensuse.org/Roadmap
Thanks,
--
openSUSE Roadmap Reminder
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Dear Factory contributors and packagers,
As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I
would like to announce that the packaging guidelines have some
extensions (not really new) that will be stricter enforced than they
used to be.
Currently a common rule to be 'ignored' or packagers are not aware is
around the topics of:
- .Changes entries
- Patches
First, the .changes entry (rpm changelog) surves two purposes:
- News for the user
- History tracking of packaging changes (often referenced in bugs to
verify if a user has the latest packaging bugfixeS).
A simple "Update to version x.y.z" is, as before, not accepted. There
should be some buzz around the update for the user; some major reasons
to the upgrade should be listed
Changes on the package itself should be mentioned in a way that any
other contributor to the same package can follow traces of why
something is the way it is. Commonly, Added (build)dependencies are
interesting to be seen, special hacks to make something work in a
particular way [..]: Always consider that package maintenance is a
distributed task and various contributors need to be able to step up
at will.
Patches:
The rules about patches are listed at
http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines .
Most prominent is likely the mentioning of the patches life cycle,
which forces you to mention additions and removals of patches in the
changelog. As history shows, this can be helpful if a patch got
removed, and later a regression is reported; finding out when a patch
was removed can be crucial in reconstructing feature sets (including
contacting the contributor that dropped it.. which is easily extracted
from the .changes if listed)
The main appeal is to the devel project maintainers / reviewers, to
keep out for those rules, to live according to them, as it is
frustrating for everybody if a package needs to be declined by the
Factory Review team:
- The dev prj maintainer is the one getting the 'decline' (as it was
usually a forwarded request), which often leaves the 'fixing' to the
devel project maintainers, where the 'originator' of the fix would
have been willing to actually do that...
And the Factory Review team also prefers to see complying submissions
to having to reject SRs... reject is not fun for anybody!
Looking forward to many more SRs to accept!
Dominique / DimStar
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Postgis packages on obs are actually maintained with 2 versions.
postgis = 1.5 series
postgis2 = 2.0 series
Upstream has released 2.1 : but this one raised some new dependencies which are no more available for SLE build.
2.1 need postgresql 9.0 SLE has only 8.x version.
also geos has to be 3.4+
Discussing with postgis members on irc reveal that will become more strict on postgresql version
The next 2.2 release will need 9.1
A 2.0.4 bug fixes release will be also made. (simple update of the actual 2.0.3)
So what should we prepare ?
have postgis21 package ? and then a postgis22 ?
Windows packaging is like this, also Ubuntu seems to follow the same way.
I've actually already have a project for the upgrade but this one would upgrade 2.0.3 to 2.1
(in term of postgis it's a soft upgrade for those running the 2.0.3)
Any through ?
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
openSUSE Member
GPG KEY : D5C9B751C4653227
irc: tigerfoot
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
Recently I'm updating our LXDE, and I met a problem
Their packages used a lot of icons from nuoveXT2-icon-theme in their
desktop files.
So I always get "Error Icon in
/usr/share/applications/pcmanfm-desktop-pref.desktop not found
"user-desktop".
Usually if it's an icon in hicolor-icon-theme, you add a
BuildRequires: hicolor-icon-theme
Then it will be automatically resolved.
But I added
BuildRequires: nuoveXT2-icon-theme
And nothing happened.
Anyone know how to workaround this?
Greetings
Marguerite
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
http://en.opensuse.org/openSUSE:Packaging_guidelines#Debuginfo
implies that package builds automatically result in -debuginfo
packages and that you have to explicitly disable them if you don't
want them, but it fails to mention:
1. how -debuginfo packages are automatically built, and
2. how to disable them.
It links to http://old-en.opensuse.org/Packaging/Debuginfo which
doesn't really answer either, save fleeting references to
/usr/lib/rpm/find-debuginfo.sh.
I found this thread:
http://lists.opensuse.org/opensuse-factory/2012-11/msg00328.html
but it doesn't appear to have a useful conclusion.
Please can someone shed light? Thanks!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Since some weeks, idzebra stopped building for i586. C expert is
required. Can someone please check why it fails, and then provide a
fix?
https://build.opensuse.org/package/show/network/idzebra
--
Karl Eichwalder SUSE LINUX Products GmbH
R&D / Documentation Maxfeldstraße 5
90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Currently python-gobject in the devel:languages:python and
python3-gobject in devel:languages:python3 are separated into two
packages.
However, python-gobject is linked to the version on openSUSE:Factory,
which still has python 2 and python 3 spec files in one package. Its
devel project is GNOME:Factory, which also still has both spec files.
This is leading to frequency breakage in the devel:languages:python
version, since it links to a package that has two spec files while it
only has one. If we are going to go with the separate packages we
should to it in factory as well.
It would be easy to provide a submit request for this. However,
currently python3-gobject in openSUSE:Factory and GNOME:Factory are
linked to their respective python-gobject packages, so doing the
submission now would break python3-gobject.
So if we are going to go with the separate python2 and python3
packages, can we do so for python-gobject as well? If not, we need to
either unlike python-gobject from factory, go back to using two spec
files, or remove it from devel:languages:python entirely (which may
not be a bad idea since it often depends on the latest GTK version
anyway).
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org