openSUSE Packaging September 2013

packaging@lists.opensuse.org

50 participants
28 discussions

[opensuse-packaging] [reminder] openSUSE 13.1 Beta is next week

by openSUSE Roadmap Reminder

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

8 years, 1 month

[opensuse-packaging] Packaging Guideline enforcement

by Dominique Leuenberger a.k.a DimStar

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

8 years, 1 month

[opensuse-packaging] Application:Geo Upgrading postgis2 - Call for comments

by Bruno Friedmann

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

8 years, 1 month

[opensuse-packaging] how to include icons from an alternative theme?

by Marguerite Su

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

8 years, 1 month

[opensuse-packaging] packaging guidelines need more info about debuginfo mechanism

by Adam Spiers

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

8 years, 1 month

[opensuse-packaging] Apresentadora Priscilla Alcantara

by PRIKOTA PRODU��ES

8 years, 1 month

[opensuse-packaging] idzebra does not build for i586

by Karl Eichwalder

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

8 years, 1 month

[opensuse-packaging] python-gobject and python3-gobject

by Todd Rme

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

8 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging September 2013