openSUSE Packaging March 2013

packaging@lists.opensuse.org

34 participants
25 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

8 years, 6 months

[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, 8 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

8 years, 9 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, 11 months

[opensuse-packaging] Creating of systemd service files instead of init scripts for new packages

by Andreas Jaeger

Since we moved to systemd completely, I suggest that newly added files will contain service files - and not init scripts anymore. So, please only add service files to new packages and if you change your init file, consider using a service file and dropping the init file, Andreas -- Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

9 years

[opensuse-packaging] Proper dev project for a small collection of C utility libs with python bindings

by Greg Freemyer

All, I'm about to submit 6 new small packages: libevt, libevtx, libregf, libmsiecf, liblnk, libvshadow. My basic question is what devel project I should send these to and if I should leave them as 6 discrete projects, or maybe try to combine them somehow. I've thought about just pushing all 6 to devel:libraries If that is a good choice let me know. == details All of them are from the same upstream author and have the same structure, all hosted at the same place etc. The specfiles are all very similar. For each one there is a c library created, a python bindings sub-package and a end-user tools sub-package (eg. evttools, etc.) with a couple simple tools each. My use case is a security tool that uses the python bindings of all 6, so in theory I could put them there, but it seems like the wrong place to me, but the "tools" sub-projects would all actually qualify as security tools for a forensic examiner. (I already have 15 or 20 forensic tools in the security project, so maybe it is time for me to create a security:dfir sub-project and just put everything in there?) Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

9 years, 1 month

[opensuse-packaging] %wx_requires, %wx_provides and %_use_internal_dependency_generator

by Matwey V. Kornilov

Hi all and Stanislav, This week I've tried to implement auto requires/provides for erlang modules. One of the issues is wx-rpm-stuff specific to openSUSE. erlang does have wx-bindings package (it is allowed to compile some C/C++ code and load as build-in functions) and this way its spec contains disabling of internal dependency generator (and this disables fileattrs stuff). I can overcome it, and I do understand that there are strong reasons to implement this specific stuff controlling different ABI. However, internal dependency generator is enabled by default in rpm 4.10 and it seems to be powerful tool. Are there plans to adapt 'libwxfoo(variant)' syntax to IDG? Can find-wx-* stuff be implemented as suse specific patch to /usr/lib/rpm/elfdeps tool? -- With best regards, Matwey V. Kornilov http://0x2207.blogspot.com xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

9 years, 1 month

[opensuse-packaging] "build" without obs backend

by Cor Blom

Hi, Sometimes I want to build a package on my machine, outside obs. The "build" script worked fine for this, until I upgraded to 12.3. I had to adapt the sl12.3.conf in /usr/lib/build/configs (libgcc%{gcc_version} --> gcc%{gcc_version}) but that is no problem. No I am stuck with the following message: [ 6s] expanding package dependencies... [ 9s] Use of uninitialized value within %packs in hash element at /usr/lib/build/expanddeps line 199. [ 9s] Use of uninitialized value in concatenation (.) or string at /usr/lib/build/expanddeps line 199. [ 9s] Use of uninitialized value within %packs in exists at /usr/lib/build/expanddeps line 200. [ 9s] Use of uninitialized value within %packs in hash element at /usr/lib/build/expanddeps line 199. [ 9s] Use of uninitialized value in concatenation (.) or string at /usr/lib/build/expanddeps line 199. [ 9s] Use of uninitialized value within %packs in exists at /usr/lib/build/expanddeps line 200. [ 9s] unsupported url for 'insserv': This is the result of executing (as root): build foo.spec Can someone help, or should I file a bug report? Thanks, Cor -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

9 years, 1 month

[opensuse-packaging] Review policy

by Togan Muftuoglu

Hi, Should there be a general review policy for the obs users who have the maintainer rights for package/group. I guess there is one for the opensuse-review team maybe we should have it also for those who are accepting packages to the devel projects as well. The reason is I had a declination with a comment why I have not explained use of %ghost macro in a spec file, but a person who would have reviewed the rpm buildlogs for the package would realize the fact that rpmlint gives the following error. non-ghost-in-var-run (Badness: 1000) And the mentioning %ghost in changes file in IMHO is nonsense as the issue has nothing to the with the package but packaging itself and from the end users point of is just cosmetic. So maybe it is a good idea to have a document describing what is required/recommended in the #sr review Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

9 years, 1 month

[opensuse-packaging] How to request an SLES/OpenSUSE package update?

by Fulko Hew

During the process of developing my app (used internally) I discovered a bug in Net-SNMP and provided the fix, which has been accepted. http://sourceforge.net/p/net-snmp/patches/1240/ The trouble is that our company is reluctant to install stuff that doesn't come directly from the vendor (even though they will install _my_ app). Whats the process for getting an up-stream patch back-ported into a new package version for SUSE/SLES? TIA Fulko -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

9 years, 1 month

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging March 2013