openSUSE Packaging February 2013

packaging@lists.opensuse.org

26 participants
18 discussions

[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

7 years, 9 months

[opensuse-packaging] Package looking for volunteers: CodeAnalyst

by Cristian Morales Vega

As per https://bugzilla.novell.com/show_bug.cgi?id=793541 it seems CodeAnalyst needs a new maintainer. Any volunteer? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 10 months

[opensuse-packaging] package looking for maintainer: the AT daemon

by Cristian Rodríguez

Hi: I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5) So it is now up for grabs. that's all ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years

[opensuse-packaging] ldconfig - I'm frustrated

by Greg Freemyer

All, I sent the httrack package to security a couple weeks ago. It builds, but with a few rpmlint issues. I thought I would clean up the one about the shared library needing to be split out to its own package. I've tried to do that in home:gregfreemyer:branches:security > httrack The diff is: https://build.opensuse.org/package/rdiff?opackage=httrack&oproject=security… I've tried multiple ways to call ldconfig. But my build always fails with: [ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin (Badness: 300) /usr/lib64/libhtsjava.so.2.0.46 [ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin (Badness: 300) /usr/lib64/libhttrack.so.2.0.46 [ 218s] This package contains a library and provides no %post scriptlet containing a [ 218s] call to ldconfig. The spec file currently has: === %post /sbin/ldconfig /usr/lib64 %postun /sbin/ldconfig /usr/lib64 === I've tried the basic versions as well. == %post -p /sbin/ldconfig %postun -p /sbin/ldconfig == %post /sbin/ldconfig %postun /sbin/ldconfig == Can anyone tell me what's going on? Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

[opensuse-packaging] guidelines for moving programs between packages

by Bernhard Voelker

Hi, are there any guidelines on how to move programs from one package to another - while guaranteeing that the program is installed any time (either by the old or by the new package)? The case: su and kill are moved from coreutils to util-linux upstreams. It'd be "quite not so optimal" if an installation would be left behind without them ... Therefore we're trying to add a hack in coreutils.rpm to install the su binary as su-core, and to create a symlink "su" pointing to it in the %post script when "su" does not already exist (i.e. is not yet installed by a newer util-linux.rpm): %post test -e %{_bindir}/su || ln -sv su.core %{_bindir}/su The problem is the order in RPM i.e. when %post is run: According to my tests, it is obviously run _before_ the old version of the coreutils package is uninstalled. Thus, su of the old version is still there, and the symlink is not created. ;-( D: %post(coreutils-8.21-0.x86_64): scriptlet start [...] D: %post(coreutils-8.21-0.x86_64): waitpid(4078) rc 4078 status 0 D: ========== +++ coreutils-8.17-6.2.1 x86_64-linux 0x0 D: erase: coreutils-8.17-6.2.1 has 287 files Cleaning up / removing... [...] D: fini 124755 1 ( 0, 0) 44288 /usr/bin/su The strangest thing is that RPM seems to behave different during `osc build` ... Any ideas? Thank you & have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

[opensuse-packaging] [reminder] openSUSE 12.3 Goldmaster is next week

by openSUSE Roadmap Reminder

Hello all, openSUSE 12.3 Goldmaster will be released next week, on Thursday 07 March 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, 3 months

[opensuse-packaging] Error in rpmlint?

by Ilya Chernykh

[ 242s] RPMLINT report: [ 242s] =============== [ 246s] (none): E: badness 10000 exceeds threshold 1000, aborting. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

[opensuse-packaging] [reminder] openSUSE 12.3 RC 2 is next week

by openSUSE Roadmap Reminder

Hello all, openSUSE 12.3 RC 2 will be released next week, on Thursday 28 February 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, 4 months

[opensuse-packaging] Changing locale settings for building a package

by Karl Ove Hufthammer

I’m working on creating a package where the ‘build’ process seems to depend on being run under a UTF-8 locale. It turns out the the package when built on the OBS succeeds, but contains an invalid file, due to improper multibyte handling. I can get the same invalid file by doing a ‘LC_ALL=C make’ on my local system. Is there a way to make OBS run under a UTF-8 locale, like ‘en_US.UTF-8’? What is the recommend way of handling problems like this? -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 4 months

[opensuse-packaging] usb flashdisk dengan logo perusahaan anda

by Marketing 10

kami menerima pesanan usb yang bisa di pesan dengan logo perusahaan anda untuk di jadikan souvenir untuk info lebih lengkap hubungi kami di email : locanojakarta(a)yahoo.com terima kasih Marketing flashdisk

8 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging February 2013