August 2013 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] CrossToolchain question
by Matwey V. Kornilov 25 Oct '13

25 Oct '13

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

5 22

[opensuse-packaging] Packaging Guideline enforcement
by Dominique Leuenberger a.k.a DimStar 10 Sep '13

10 Sep '13

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

29 105

[opensuse-packaging] python-gobject and python3-gobject
by Todd Rme 02 Sep '13

02 Sep '13

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

2 2

[opensuse-packaging] Install section not completely executed on local build
by Matthias Fehring 30 Aug '13

30 Aug '13

Hello list, in the following spec file, in the install section other parts than %kde4_makeinstall are not executed when I try to build it local with osc build. https://build.opensuse.org/package/view_file/home:buschmann23:Active:Unstab… The remote build in the Build Service runs as expected, but in the local build it executes only pushd builddir %kde4_makeinstall popd Best greetings Buschmann -- Das Gesetz hat zum Schneckengang verdorben, was Adlerflug geworden wäre. (Friedrich Schiller - Die Räuber) Und der Buschfunk spielt gerade "The First Drop" von "Rise Against". www.buschmann23.de GPG-Key: 0x720AADE0

2 1

[opensuse-packaging] Another python related query
by Greg Freemyer 28 Aug '13

28 Aug '13

Sascha, Since you're the python guru, I just noticed that you put python-scapy in D:L:P a few months ago and sent it to factory. The D:L:P version has a tarball version of "latest" which could mean anything. The specfile says 2.1.0 That's great, except scapy is also in security and it's version 2.2.0 there. I'm not positive security:scapy is the same thing as D:L:P:python-scapy, but the description of both is the sames o it sure looks like it. Seems like a D:L:P python-scapy should be updated to 2.2.0 and security-scapy either trashed or linked to D:L:P fyi: I haven't used scapy yet, I was just looking to see if we had it packaged so I could try it out and was surprised to see it twice. Thanks 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

2 3

[opensuse-packaging] SONAME question
by Greg Freemyer 28 Aug '13

28 Aug '13

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

6 8

[opensuse-packaging] osc meta - what is the xml syntax?
by Greg Freemyer 28 Aug '13

28 Aug '13

All, I'm getting this error and don't know where to look for the right syntax: === Sending meta data... BuildService API error: validation_failed (400) package validation error: Element package has extra content: repository === I'm using this as a reference, but maybe I either it is out of date or I'm missing something basic: https://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#Adding_multi… I created test package with this xml: <package name="plaso_test_install_package" project="home:gregfreemyer:junk"> <title></title> <description>Test package to see if plaso will install in fedora. ie. Are all the dependencies present.</description> <repository name="openSUSE_12.2"> <path project="devel:languages:python" repository="openSUSE_12.2"/> <path project="openSUSE:12.2" repository="standard"/> <arch>i586</arch> <arch>x86_64</arch> </repository> </package> 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

2 1

[opensuse-packaging] Help Wanted: openSUSE Review Team
by Craig Gardner 27 Aug '13

27 Aug '13

Dear Awesome openSUSE Community, The openSUSE Review Team is interested in adding 1 to 2 new members to the team. This person will review submissions to opnSUSE Factory that will improve the quality of the product and add great new functionality to the already awesome openSUSE distribution. Details of the tasks performed by the members of the Review Team can be seen on the openSUSE Review Team wiki page [1] and the associated openSUSE Factory Submissions portal [2]. Ideally we want to add a non-SUSE employee from the community, but all qualified candidates will be considered. (Dominique "Dimstar" Leuenberger would really appreciate some more non-SUSE folks on the team. Who can blame him?!) A qualified candidate would display the following characteristics: a) works well with the Review Team and the openSUSE (and greater Linux) community b) considerable expertise with RPM packaging c) considerable expertise with openSUSE packaging methods and standards d) reasonable awareness of Linux security concerns e) an appreciation for quality controls and the value of solid, quality software f) an availability to routinely perform these tasks for the community. Typically a few hours per week divided over several days during the week. g) willing to apply the rules to everybody; primary goal is to safeguard quality, not friendship :) You're even allowed to decline coolo's request! Applications will be considered until 9 September 2013. If you're interested, please send email to the Review Team via review(a)opensuse.org. (Please don't reply directly to this opensuse-packaging mailing list.) In your email, tell a little about yourself, particularly about the "a" through "g" qualifications listed above. Oh, and don't forget to have fun. [1] https://en.opensuse.org/openSUSE:OpenSUSE_review_team [2] https://en.opensuse.org/openSUSE:Factory_submissions -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Need some help/advise for python packaging
by Robert Schweikert 26 Aug '13

26 Aug '13

Hi, I need to package gcutil and gsutil, starting with gcutil (https://code.google.com/p/google-compute-engine-tools/ , https://developers.google.com/compute/docs/gcutil/#install) For better or worse the guys at Google decided not to create a setup.py file and assume that everything they need is installed in the location where the main "executable" is installed. That's not very nice of course from a packaging perspective as I think their modules should end up in site-packages and the script should live in /usr/bin. I've created the following setup.py file: import setuptools setuptools.setup( name = 'gcutil', version = '1.8.2', description = 'Utilities to control Google Compute Engine resources', author = 'Robert Schweikert', author_email = 'rjschwei(a)suse.com', url = 'https://code.google.com/p/google-compute-engine-tools/', packages = setuptools.find_packages('lib'), package_dir = {'': 'lib'}, ) With this I ended up with /usr/lib/python2.7/site-packages/gcutil-1.8.2-py2.7.egg/EGG-INFO/scripts/gcutil where "gcutil" is the "executable". None of the code in the "lib" directory ended up in site-packages. What's the correct approach here? I could of course just simply copy the whole kit and caboodle to the site-packages directory and create a link from /usr/bin, but somehow that does not feel very satisfying and appears like taking the easy way out, but maybe that is acceptable? Eventually I'd like to have this in Factory. Help is much appreciated. As I do not know the correct direction to take I have o spec file or package to share in OBS yet. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 5

[opensuse-packaging] ruby dependencies - what's the correct way?
by Christian Boltz 26 Aug '13

26 Aug '13

Hello, I just got SR #195618 ( https://build.opensuse.org/request/diff/195618 ) declined because: > Ruby dep seems wrong. > > It states that it needs: > ruby = 2.0.0 > but our ruby is versioned like this: > ruby-2.0-3.2 In my spec, I have Requires: ruby = %{rb_ver} and going down the rpm macro chain, I found that rb_ver contains the result of # /usr/bin/ruby2.0 -r rbconfig -e 'print RbConfig::CONFIG["ruby_version"]' 2.0.0 This at least explains why it's wrong ;-) What's the correct way to specify the ruby dependency? BTW: the package also contains "2.0.0" in the directory name: # rpm -qpl ruby-apparmor-2.8.2-156.1.x86_64.rpm /usr/lib64/ruby/site_ruby/2.0.0/x86_64-linux/LibAppArmor.so Regards, Christian Boltz -- Du hast jetzt relativ kompliziert die völlig korrekte Aussage: "SPF ist krank, funktioniert nicht und vom Ansatz her bereits defekt." formuliert. [Peer Heinlein in postfixbuch-users] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1