openSUSE Packaging July 2015

packaging@lists.opensuse.org

26 participants
22 discussions

[opensuse-packaging] release-notes-openSUSE requires google-opensans-fonts

by Felix Miata

TW $SUBJECT can't be right, but trying to zypper rm opensans wants to remove releasenotes. :-( -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 2 months

[opensuse-packaging] Introduce golang-packaging

by Marguerite Su

Hi, friends, Last month I saw some posts in this list complaining that our devel:languages:go is not packager friendly, eg, we don't have "golang(google.golang.org/cloud/compute/metadata)" style BuildRequires, and package names are not intuitive (not following golang's importpath so when an error about importpath occurs, packager don't know which package provides it) So I coded. https://github.com/marguerite/golang-packaging devel:languages:go/golang-packaging This is inspired by the logic behind the nodejs-packaging packge in devel:languages:nodejs. nodejs-packaging is developed by Fedora/RedHat package maintainers, using the brand-new system RPM 4.9 provides: http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator Basically it has two parts: * matching rule * scripts to generate Provides/Requires When a RPM is being built, if file will install to the dir that mentioned by the regex matching rule, the self-maintained scripts will be called and the generated Provides/Requires will be attached along with the regular Provides/Requires. So I wrote two scripts: 1. golang.prov will extract importpath from specfile: "%define importpath xxx" > "%goprep xxx" > URL: xxx and all the sub-directories in /home/abuild/rpmbuild/BUILD/gocloud-%{version}(this is detected by "Source" tag), that is because both "google.golang.org/cloud" and "google.golang.org/cloud/compute/metadata" are valid importpaths in golang. 2. golang.req will extract such lines from all *.go files (except for those .go files inside examples/test directory and *_test.go files, because examples/tests are useless in production environment, with the imports inside them): * import "xxx" * import { xxx "xxx" } * import xx "xxx" these lines can actually be treated as golang's "include" or build/runtime Requires. and generate such golang() Requires. So if you're a golang packager, now you can just "BuildRequires: golang-packaging" and let my scripts to handle Provides/Requires for you automatically. with this, you can also "BuildRequires: golang(xxx)" for packages built with golang-packaging. Additional information: 1. If there're unneeded importpath in examples/tests, just leave them there, my package will skip them. If such importpath resides in main .go source codes, "%go_strip_builddep xx" in %prep step can help you strip them manually. 2. there's one shortcoming, the same as the one for nodejs-packaging: The build "success" status for a package doesn't mean the package can be installed without any problem. Because there might be non-fulfilled Requires for the package, remember to check it again using page like this: https://build.opensuse.org/package/binary/devel:languages:go/golang-org-x-t… As to package renames: I just follow the Fedora style: golang + importpath like string, eg: golang-github-golang-glog refers to github.com/golang/glog. basically importpath with ".org/.net/.com" will be okay with my package. You can refer to the golang-* packages I recently send to devel:languages:go as examples. Welcome to help golang package renaming and contribute to my package :-) Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 10 months

[opensuse-packaging] How to avoid more undefined symbols?

by SF Markus Elfring

Hello, I came along two issues recently where symbols from C++ class libraries which were provided by specific software package versions did not fit together temporarily. Combinations: * libmodman1 / libproxy1 https://bugzilla.opensuse.org/show_bug.cgi?id=937157#c5 * yast2-core / libyui6 https://bugzilla.suse.com/show_bug.cgi?id=937665#c2 How are the chances that such name mangling changes because of application binary interface adjustments will trigger appropriate updates automatically? Do dependency descriptions need any more fine-tuning for corresponding RPM specifications? Regards, Markus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 10 months

[opensuse-packaging] Force specific Lua version as build requirement

by Green Basilisk

Hello, how do I force a specific Lua version as build requirement independently of the used openSUSE version? In Tumbleweed, 13.2, etc. the Lua package contains version 5.2. In Factory the Lua package provides version 5.3. However, the programm I want to package needs version 5.2. Using ------ BuildRequires: lua BuildRequires: lua-devel ------ works for Tumbleweed, 13.2, etc. but not for Factory. In contrast ------ BuildRequires: lua52 BuildRequires: lua52-devel ------ works only with Factory because these package are not available in the other openSUSE versions. I first tried to distinguish between Factory and Tumbleweed but that seems to be impossible. Is that correct? I also tried to query the Lua version but since subshell expansions don't work in OBS for BuildRequires (see https://en.opensuse.org/openSUSE:Specfile_guidelines#OBS_Caveat) I was not successful. My solution is now to use lua52 and lua52-devel as build requirements and to include the repository devel:languages:lua to Tumbleweed, 13.2, etc. to have packages with that name. This seems to work (see https://build.opensuse.org/package/show/home:greenbasilisk:branches:graphic…) but I don't know if that is an appropriate solution. Heinz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 10 months

[opensuse-packaging] npm packaging in devel:languages:nodejs (split or integrate?)

by Marguerite Su

Hi, all, As you may noticed, npm has been splitted from nodejs main package since openSUSE 13.2. If I remembered correctly, the reason of the split given was: to get the latest updated npm. But now it has been proved that the split is a total failure. It not only increased the possibility of a broken npm in openSUSE:Factory but also increased the difficulty to maintain npm. And it can not even guarantee a latest updated npm at all. Let me explain the situation now: 0. If npm is built from the nodejs package, we only need to maintain one package. If npm is splitted as it is now, we have to maintain about 40 packages and their dependencies, it is about 100+ packages as I counted. 1. nodejs-packaging is not a tool good for aggegation. eg: if you just build one package, you can check its dependencies found by nodejs-packaging through the OBS website; but if you're going to build 100 of such packages, it's very very time-consuming for you to do that one by one. And there's no way to have all the dependencies and sub-dependencies at one time, the only similar tool existed is "npm shrinkwrap", but it requires the latest npm installed first, or it can only give the all-in-one dependecy map of the old installed npm. 2. And even this tool has conflicts with nodejs-packaging. "npm install npm" will always installs a npm. But actually nodejs's dependency checking is not as strict as nodejs-packaging. so even if you update the packages based on "npm shrinkwrap" (I don't want to mention the funny stuff like you want to update npm you have to have an updated npm installed first), nodejs-packaging will still triggers a lot of conflicts. Many of them are actually not resolveable at all, eg: package A needs 0.8 version of package C, but package B needs 1.2 version of package C, package A and B are both dependencies for npm. what should be done now? As a maintainer you have to read the git commit logs of package C to see what happened between 0.8 and 1.2, to see if it is safe to bump/downgrade version for A or B. If you're lucky enough, it can be done no matter how painful it is. But if you're not so lucky, you have to provide both 0.8 and 1.2 version, that comes update-alternatives (which is questionable because in this case 0.8 and 1.2 will be installed both, what if a file from 0.8 is used with other files from 1.2? is it safe? no one knows). 3. nodejs-packaging's check result is not shown to you unless you submit all packages to openSUSE:Factory. This means npm will be always broken in devel:languages:nodejs because no one knows which package is a dependency for npm and remember not to touch it! So if you accept a single request to update a package, it is very likely that the whole npm chain breaks. Even if the results are shown to you now, you can't be sure factory maintainers accepts your requests at the same time. That means npm in Factory is very likely to break. And as we introduced staging projects, a single request accepts much faster than 100+ requests. 4. Actually the person who proposed the split never maintain npm after 2 or 3 submits. And 100+ packages really need lots of manpower. If I want to update npm today, I can finish the work a month later if I do nothing but to update nodejs-* packages once I login to OBS. While npm will see 2 or 3 releases during that time, that means we will be always late. So here's what I want to do: 1. everything stops now, all npm dependencies will be removed from Factory (writing Obsoletes will be a lot of work, see you in a month), and npm builds from nodejs main package from now on. 2. someone steps in to maintain the packages with a program. Because it's not doable for a human being as I told above. Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 10 months

[opensuse-packaging] How to use BuildArch ExclusiveArch ExcludeArch correctly?

by Johannes Meixner

Hello, I have a package that contains only bash scripts (plus documentation) and therefore it is currently BuildArch: noarch But depending on the run-time architecture it requires different packages and therefore it has in its spec file -------------------------------------------------------------- %ifarch %ix86 x86_64 Requires: syslinux %endif %ifarch ppc ppc64 Requires: yaboot %endif -------------------------------------------------------------- But that cannot work because when it is built as "noarch" none of the %ifarch matches which means neither syslinux nor yaboot will be required by the resulting *.rpm package. I did not find openSUSE documentation how to solve this. The Fedora Packaging Guidelines https://fedoraproject.org/wiki/Packaging:Guidelines contain an "1.9 Architecture Support" section that contains (excerpt): -------------------------------------------------------------- Requires When your package needs the problematic dependency at runtime but not at build time then you only need to keep it from entering the package repositories for that architecture. There is a relatively simple workaround for this: BuildArch: noarch # List the arches that the dependent package builds on below ExclusiveArch: %{ix86} %{arm} x86_64 noarch -------------------------------------------------------------- I don't know if -------------------------------------------------------------- BuildArch: noarch ExclusiveArch: %ix86 x86_64 ppc ppc64 noarch %ifarch %ix86 x86_64 Requires: syslinux %endif %ifarch ppc ppc64 Requires: yaboot %endif -------------------------------------------------------------- is allowed and/or works on openSUSE. I found a strange looking example at openSUSE: -------------------------------------------------------------- $ osc cat openSUSE:13.1 libreoffice-l10n libreoffice-l10n.spec ... BuildArch: noarch #!ExclusiveArch: %ix86 x86_64 ppc ExcludeArch: ia64 s390 s390x -------------------------------------------------------------- I do not understand that. In particular what "#!ExclusiveArch:" means? Why not plain "ExclusiveArch:"? Furthermore at run-time the bash scripts in that package actually work only on a few supported architectures namely %ix86 x86_64 ppc ppc64. Therefore I like to specify only those architectures where the package actually works. I like to avoid that those bash scripts can be "just installed" on architectures that are actually not supported (i.e. I like to avoid that the package can be built by accident on architectures where it actually cannot work). Would it work to simply have only -------------------------------------------------------------- ExclusiveArch: %ix86 x86_64 ppc ppc64 %ifarch %ix86 x86_64 Requires: syslinux %endif %ifarch ppc ppc64 Requires: yaboot %endif -------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 10 months

Re: [opensuse-packaging] Force specific Lua version as build requirement

by Green Basilisk

Hello Axel, "Dr. Axel Braun" <axel.braun(a)gmx.de> writes: >> However, doesn't it make sense to add >> provides: lua53 >> to the Lua package to avoid this hassle in future? > > Not sure if I understand your approach. > I think that does not make sense - you can always derive the version > from the > package. What do you mean with _derive_? However, I will try to explain my thoughts: The current naming scheme of the Lua packages is - lua for the latest version at the time point when the openSUSE version was released - lua50, lua51, etc. for all older Lua versions Thus for example in openSUSE 13.2 lua package = Lua 5.2.x lua51 package = Lua 5.1.x lua50 package = Lua 5.0.x Now in Tumbleweed and Factory we have lua = Lua 5.3.x lua52 = Lua 5.2 lua51 = Lua 5.1.x lua50 = Lua 5.0.x This naming scheme is also explained in https://en.opensuse.org/openSUSE:Packaging_Lua#Addon_packages As a consequence, packagers have to fiddle with %if-suse_versions every time when the Lua versions increases. Additionally, in the period where Factory had already upgraded the Lua version and Tumbleweed not, one of them failed to build. My suggestions is to name in Tumbleweed and Factory the lua package also lua53. This would make the life easier because if you have to package a program which requires lua53 you can just write BuildRequires: lua53-devel and it will stick to that version. I don't know if naming the latest lua package also lua53 has any side effect. However, when upgrading to Lua 5.4, it will be named lua53 anyway. Best regards, Heinz "Dr. Axel Braun" <axel.braun(a)gmx.de> writes: > Hello Heinz, > > Am Montag, 27. Juli 2015, 11:42:05 schrieb Green Basilisk: > >> I think the problem vanished because now Tumbleweed and Factory are >> aligned in terms of Lua versions. :) >> >> However, doesn't it make sense to add >> provides: lua53 >> to the Lua package to avoid this hassle in future? > > Not sure if I understand your approach. > I think that does not make sense - you can always derive the version from the > package. > Except you want to replace lets say the gizmo-package with the more advanced > gizmo-turbo. Then you could add a > prevides: gizmo > (a version higher than the current gizmo package) > to gizmo-turbo to force the change > > Cheers > Axel > > -- > Dr.-Ing. Axel K. Braun > Mobile: +49.173.7003.154 > VoIP/Skype: axxite > PGP Fingerprint: CB03 964D 1CFA E87B AA63 53F3 1BD6 F53A EB48 EF22 > Public Key available at http://www.axxite.com/axel.braun@gmx.de.asc > > This mail was *not scanned* before sending. > It was sent from a secure Linux-Desktop: > > ThinkPad T520 > OS: openSUSE 13.1 (x86_64) > Kernel: 3.11.10-29-desktop > KDE: 4.14.10 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 11 months

[opensuse-packaging] missing or wrong dependencies in d:l:ruby:extensions

by Olaf Hering

What needs to be done to install for example cucumber in SLE_12 or TW? Since I know next to nothing about ruby my naive approach goes like this: root@c111:~ # env -i zypper -vv se -sdt package cucumber ... | ruby2.2-rubygem-cucumber | package | 2.0.2-1.1 | x86_64 | ruby_extensions ... root@c111:~ # env -i zypper -vv in ruby2.2-rubygem-cucumber Verbosity: 2 Non-option program arguments: 'ruby2.2-rubygem-cucumber' Initializing Target Checking whether to refresh metadata for perl Checking whether to refresh metadata for python Checking whether to refresh metadata for ruby Checking whether to refresh metadata for ruby_extensions Checking whether to refresh metadata for tw-Essentials Checking whether to refresh metadata for tw-Extra Checking whether to refresh metadata for tw-Games Checking whether to refresh metadata for tw-Multimedia Checking whether to refresh metadata for tw-debug Checking whether to refresh metadata for tw-non-oss Checking whether to refresh metadata for tw-oss Loading repository data... Reading installed packages... Force resolution: No Selecting 'ruby2.2-rubygem-cucumber-2.0.2-1.1.x86_64' from repository 'ruby_extensions' for installation. Resolving package dependencies... Force resolution: No Problem: nothing provides rubygem(ruby:2.2.0:cucumber-core:1.2) >= 1.2 needed by ruby2.2-rubygem-cucumber-2.0.2-1.1.x86_64 Solution 1: do not install ruby2.2-rubygem-cucumber-2.0.2-1.1.x86_64 Solution 2: break ruby2.2-rubygem-cucumber-2.0.2-1.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 11 months

[opensuse-packaging] adding Recommends for ruby packages

by Olaf Hering

What is the best way to add recommends for a ruby package? Looks like rubygem-net-ssh should get a Recommends: on Highline according to /usr/lib*/ruby/gems/*/gems/net-ssh*/lib/net/ssh/prompt.rb Otherwise the passphrase is echoed to stdout. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 11 months

[opensuse-packaging] Python 2 and 3 in single specfile

by Jan Matějek

Fellow packagers, after some discussions in our team, we figured that it would be neat if we could build python modules for Python 2 and 3 from a single spec file. Now that a great deal of python modules work with both pythons, this makes a lot of sense. A good deal of work can be done by RPM macros. Then we could even seamlessly start building modules for PyPy, Jython and other pythons. A sample specfile, and the corresponding set of RPM macros, is attached. As you can see, the appropriate subpackage is generated automatically by %python_subpackages, build and install steps are handled through %python_build and %python_install respectively. There is some more magic involved, as well as possibilities for customization. There is a minor problem with BuildRequires. As long as you only need python-devel, it's not too bad to just list $flavor-devel requirements by hand. It's worse when you require more subpackages, because then you need all of them in both python2 and python3 versions. It would be nice to be able to specify %{python_require Mako} and expand that to all the necessary BuildRequires, but OBS blocks us here, because the limited environment will not expand such macros. mls, ro, or anyone from the OBS team, would it be possible to solve this? Still, it basically doesn't matter if you list all the BuildRequires twice in one spec or in two specs, so there. Another thing I'm still unclear on are the filelists. It's certainly possible to make a generic filelist, something along the lines of: %package -n %flavor-%modname # python3-Mako %defattr(-, root, root) %{%flavor_sitelib}/* %{%flavor_sitearch}/* but this doesn't solve docs and possible other files. Again, obviously, we can write the filelists by hand. But if you have good suggestions for some smart macros here, I'd love to see them. What do you folks think? Comments, questions? m.

5 years, 11 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging July 2015