openSUSE Packaging July 2013

packaging@lists.opensuse.org

28 participants
23 discussions

[opensuse-packaging] CrossToolchain question

by Matwey V. Kornilov

Hi, In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one). What guidelines/rules should I follow to create CrossToolchain subproject for yet unsupported arch? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 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

7 years, 2 months

[opensuse-packaging] SONAME question

by Greg Freemyer

I just updated filesystems:ntfs-3g_ntfsprogs to have a new SONAME (83 -> 84) Do I need to add a Obsoletes: statement? Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 3 months

[opensuse-packaging] Packaging of Plee the Bear and Andy's Super Great Park

by Julien Jorge

Hello, I am a developer of open source games and I would like to see them in various Linux distributions. These games are Plee the Bear http://www.stuff-o-matic.com/ptb/ and Andy's Super Great Park http://www.stuff-o-matic.com/asgp/ Both are available under the GPL 2 and CC by-sa licenses. The source code is available on their respective websites. Would you accept to package these games for OpenSUSE ? Best regards, Julien Jorge Stuffomatic P.S.: I am not registered on the mailing list so please CC me in your responses. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 3 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, 3 months

[opensuse-packaging] Packaging PEAR modules

by Robert Munteanu

Hi, I'm going to update some PEAR packages from server:php:applications . Do we have a better way of defining dependencies other than inspecting the bundled package.xml and then updating the spec file? The Packaging PHP page [1] is silent on this topic. I know we a nice gem2rpm helper for Ruby packages and something similar for PEAR modules would be quite nice. Robert [1]: https://en.opensuse.org/openSUSE:Packaging_PHP -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 3 months

[opensuse-packaging] how to contribute package to repository

by Ovcharov Dmitry

Dear sirs, Our company is software developer. Our software is proprietary RDF database. We would like to include our software package in the official Linux distribution repository. What do we need for this? A special license? Should we open source codes? Best regards, Dmitry Head of Department system administration -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 4 months

[opensuse-packaging] condition test for a local build?

by Greg Freemyer

All, I need to have a pre-compile test that only runs if it is a local build. How do I do that? == details I maintain one package (python-plaso) that comes with a optional pre-compile test module to verify that for 6 specific libraries the latest available libraries are installed prior to building. It's a python script that looks on the Internet for the latest available tarballs for the 6 libraries. LIBYAL_URLS = { 'libevt': 'https://googledrive.com/host/0B3fBvzttpiiSYm01VnUtLXNUZ2M/', 'libevtx': 'https://googledrive.com/host/0B3fBvzttpiiSRnQ0SExzX3JjdFE/', 'liblnk': 'https://googledrive.com/host/0B3fBvzttpiiSQmluVC1YeDVvZWM/', 'libmsiecf': 'https://googledrive.com/host/0B3fBvzttpiiSVm1MNkw5cU1mUG8/', 'libregf': 'https://googledrive.com/host/0B3fBvzttpiiSSC1yUDZpb3l0UHM/', 'libvshadow': 'https://googledrive.com/host/0B3fBvzttpiiSZDZXRFVMdnZCeHc/', } I maintain all 6 of those too, so when I build python-plaso locally, I'd like it to bark if those are out of date. Alternatively, there are about 25 similarly structured libraries (libyal - yet another library). What would need to be done for the auto-version checker for factory to notice there is a new tarball and put in my routine factory status email? (That may already work, the download tarballs being hosted on a googledrive is something that just started a few months ago and I am just now updating the DL_URL fields in my spec files. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 4 months

[opensuse-packaging] Version numbers with '+' and '~' in them?

by Greg Freemyer

Why does rpmlint consider 0~20130416 older than 0.0.0+20130128 ? Does RPM/zypper have the same logic? Is there some way to do a rename (Obsoletes / Provides) to move from 0.0.0 versioning to 0 versioning? == details I've got a package that has been in 12.2 and 12.3 named as: ewftools v0.0.0+20120813. It is currently in factory as v0.0.0+20130113 It's part of a library toolset known as libyal. (about 20 libyal packages in factory now). When the rest of the libyal packages were created post 12.3 they were versioned like libyal-tools v0~20130416, so I'm trying to update the libewf package to create a libewf-tools package that will supersede the old ewftools package Thus I added: Obsoletes: ewftools <= 0.0.0+20130128 Provides: ewftools = %{version} But rpmlint is complaining: libewf-tools.i586: W: self-obsoletion ewftools <= 0.0.0+20130128 obsoletes ewftools = 0~20130416 Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 4 months

[opensuse-packaging] [reminder] openSUSE 13.1 Milestone 4 is next week

by openSUSE Roadmap Reminder

Hello all, openSUSE 13.1 Milestone 4 will be released next week, on Thursday 08 August 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

7 years, 4 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging July 2013