openSUSE Packaging December 2016

packaging@lists.opensuse.org

12 participants
7 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

5 years

[opensuse-packaging] zypp dependencies

by Wolfgang Rosenauer

Hi, during upgrade to 42.2 I found a small dependency problem which is not resolved correctly with zypper (in my opinion) but probably I missed something. (Someone else just reported the same symptom in bugzilla but closed it again because he fixed it manually.) Hygiea:~ # rpm -q --recommends MozillaFirefox | grep avcodec libavcodec-full >= 0.10.16 Hygiea:~ # zypper search -s --provides libavcodec-full Repository-Daten werden geladen... Installierte Pakete werden gelesen... S | Name | Typ | Version | Arch | Repository --+--------------+-------+------------+--------+----------------------------- i | libavcodec56 | Paket | 2.8.8-24.1 | x86_64 | openSUSE-42.2-0 v | libavcodec56 | Paket | 2.8.8-25.2 | x86_64 | Packman repository (Factory) v | libavcodec57 | Paket | 3.2-4.1 | x86_64 | openSUSE-Leap-42.2-Update v | libavcodec57 | Paket | 3.1.3-2.1 | x86_64 | openSUSE-42.2-0 i | libavcodec57 | Paket | 3.2-6.2 | x86_64 | Packman repository (Factory) I think here is the problem. This output suggests that both variants for those package (openSUSE and packman) provide that. But this is not the case as can be seen here: Hygiea:~ # rpm -q --whatprovides libavcodec-full libavcodec57-3.2-6.2.x86_64 Therefore this is a typical upgrade problem when the upgrade is performed via dup and non-official repos turned off which I would consider best practice but even if the packman repo is enabled again the recommended package is not automatically being pulled. Is this a dependency resolving bug in libzypp or did I miss something? Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 4 months

[opensuse-packaging] how to use boost-devel in Leap?

by Olaf Hering

A few packages have "Requires: boost-devel" in their -devel subpackage. This leads to unresolved dependencies like this: have choice for boost-devel needed by whatever-devel: boost_1_58_0-devel boost-devel This happens only in Leap 42.1 and 42.2. How is boost supposed to be used? If there are indeed two packages providing the same thing within a prj, then this base prj must add the relevant Prefer:. And for some reason this started to happen only recently, the last successful build is from 2016-12-02. Olaf

5 years, 5 months

[opensuse-packaging] Packaging Amazon SSM Agent

by Sean Marlow

Hi, I'm new to packaging and to Go and I'm working on packaging the amazon-ssm-agent (https://github.com/aws/amazon-ssm-agent). Using version 1.2.290.0 on GitHub yields multiple vendor issues which seem to be caused by the package structure, but I could very likely be doing something wrong. I'm using the spec file provided in the codebase, https://github.com/aws/amazon-ssm-agent/blob/master/packaging/amazon-linux/…, as an example to build the spec for SUSE. On "go build" an error is produced: imports github.com/aws/aws-sdk-go/vendor/github.com/go-ini/ini: use of vendored package not allowed To resolve this I removed the vendor directory from aws-sdk-go as both dependencies exist in the amazon-ssm-agent vendor directory. Is this the correct resolution for this issue? Now it produces another error: imports github.com/aws/aws-sdk-go/vendor/github.com/go-ini/ini: must be imported as github.com/go-ini/ini Searching the code base all imports for go-ini are imported as github.com/go-ini/ini so I'm confused what this error is hinting to. Does this mean go cannot find the dependency in the proper vendor directory (amazon-ssm-agent/vendor/...)? The final thing I noticed with this package is that vendor has an extra src directory which doesn't match the Go documentation. (amazon-ssm-agent/vendor/src/github.com rather than amazon-ssm-agent/vendor/github.com) I removed the src directory from the tree and attempted to re-build but it yields the same error. My thinking is that go looks for the dependencies at vendor/github.com/... and thus the extra directory prevents all dependencies from being resolved. Is this assumption correct or am I missing something here? Sorry for the extensive email I hope it makes some sense and thanks in advance for any help and/or knowledge you can share. Cheers! -- Sean Marlow Public Cloud Developer sean.marlow(a)suse.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 5 months

[opensuse-packaging] A helping hand for SR#444768 (shorewall)

by Bruno Friedmann

After a (too) long time, I was able to rework netfilter:shorewall package. Yes I can accept myself my SR, but as it should goes afterward to Factory, I'm willing to have at least one second pair of eyes to detect big mistakes if any. https://build.opensuse.org/request/show/444768 I've cleanup to all non openSUSE target, and also all %if for older version. I've tested myself the package and everything seems to goes at I was expecting. Thanks for your help. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 5 months

[opensuse-packaging] python single-spec, december edition

by jan matejek

Hello packagers, this is a progress report on the singlespec project. I also have some things to discuss. These are way down in the e-mail, under a heading. If you don't want to read all of it, please at least scroll down to the "Remaining issues" section. 1. Changes from last time ------------------------- In the last month, I've made a number of significant improvements to the macro set. 1.1 Backwards compatibility This one is the biggest: we can now build new-style packages in old distributions without any prjconf changes. The trick consists of two parts: - placing the macro definitions in a separate python-rpm-macros package, which is then buildrequired. You can simply link the package to your project, or we might push it into SLE/Leap build base. - shimming the %python_module definition in the spec file. Since the main purpose of this macro is to avoid repetitive listing of buildrequires, we can conditionally define it to expand to "python-$1 python3-$1" -- or, if needed, just "python-$1" -- and this will do the necessary work. The d:l:py:singlespec repository now builds packages for all distros from 13.2 up. In principle, nothing is stopping us from supporting SLE11 too, but with all the other compatibility requirements, I consider it not worth the effort. This also means that you can now easily build singlespec packages in your own repository. Just link python-rpm-macros from d:l:py:Factory. 1.2 Macro naming Naming is now very much unified. Every macro name is prefixed with the "flavor" name, which is the name of the binary in /usr/bin. That means no short versions: %python2_version, %python3_version. If we ever add, say, Jython, it's going to get %jython3_version. Some short versions are retained as compatibility spellings, namely "%py_ver". I have, however, dropped the old macro set "%py_sitedir, %py_incdir" etc. I don't think they are used anywhere; if they are, we will find out soon enough. 1.3 Fedora compatibility I have based some macro definitions on Fedora [1]. I claim _partial_ compatibility: we don't have macros for wheels and eggs. They look simple enough that I'll probably add them. I also didn't copy SRPM macros, because I have no idea what they are good for. If some Fedora people want me to include them, please explain :) As stated above, the primary spelling of all macros is with long names: %py2_compile in SUSE will be an alias for %python2_compile. The latter is the preferred spelling. [1] http://pkgs.fedoraproject.org/cgit/rpms/python-rpm-macros.git/tree/ 1.4 Package naming You can name your package anything (usual scenario is "python-foo"). In older distros, the result will be python-foo, python3-foo (and possibly pypy3-foo). In newer distros (as soon as I submit the new Python 2 package that Provides "python2-*" symbols), the result will be python2-foo, python3-foo and an empty package python-foo. I don't think I can get rid of the empty package, but the python2-foo packages are created with obsoletes/provides on the name. In order to accomplish this trick, if your package is called "python-foo", you have to decorate all %files sections: "%files %python_files", or "%files %{python_files subpkg}". The build will fail if it detects an undecorated %files section. This is not necessary if your top-level package is called "python2-foo", "python3-foo" or anything else. 1.5 %pycache_only In addition to %ifpython2, %ifpython3 etc, I have added a %ifpycache section and a corresponding %pycache_only marker. This is equivalent to "if not python2", and is applicable for flavors that use the "__pycache__" directory to store .pyc files. 1.6 %python_expand This macro will repeat its arguments for every flavor, replacing "$python" with the flavor name. For example: %{python_expand cp command-%$python_bin_suffix %{buildroot}%{$python_sitelib}/foomodule/command} I'm still not sure if this is a good idea -- after all, it's introducing a minilanguage specific to Python packages. But it sure is useful. 2. Remaining issues ------------------- New-style packages, "python2-foo", rely on presence of prjconf-based definition of %python_modules. Before we can submit packages to Factory, we need to get the definitions there. This should pose no problem, however. In two packages now I have run into a situation where I want to create a subpackage that is _not_ automatically replicated. In the first case, python-pycparser has some data that can be shared between the versions; in the second, for python-Sphinx, i want to create a subpackage for the binaries that has a dependency only on the Python 3 version. Both cases can be solved in a different way, however, the need for non-replicated looks like an important feature. How to implement it? One idea is to not replicate any %package -n something. Subpackages of this type are currently buggy, changing the bugginess to straight out ignoring is easy enough :) And conversely, it is unclear how to replicate packages of this kind anyway, so declaring them to be non-replicating is sort of natural. Another option is to delineate packages by a macro, say, %python_noreplicate. What do you think? Requires, Suggests and Recommends are copied from the main package declaration and changed to match the python flavor. It is somewhat unclear what to do about Provides and Obsoletes. They should probably be handled similarly, except the autoconverter should wrap them in %python2_only by default. On a related note, the %ifpython2 and %python2_only macros were originally intended for use both in Requires and %files. However, with the new style packages, python-foo.spec generating python2-foo.rpm and empty python-foo.rpm, this will have some flaws. Namely the requires/provides will be the same in the empty python-foo as in the correct python2-foo. I foresee this causing problems: "have choice for python-provided-symbol: python-foo python2-foo". There is a number of solutions: 1. I can hack %python2_only to work properly, and invent an alternate spelling for %ifpython2. Maybe %ifpython2_requires? I can then detect whether the correct spelling is used and halt the build if it is not. I don't like this too much, for obvious reasons :) 2. I can detect said macros and halt build without alternative, forcing the packager to rename the whole package to python2-foo or python3-foo, which would sidestep the problem. 3. I can simply not care and let the empty package have the same obsoletes/provides. This would be great if we could cripple the empty package in some other way. Introduce an unsatisfiable requirement? "Requires: this-does-not-exist" or "Conflicts: aaa_base"? Would this help zypper resolve the choice? Is there a different option for saying "this package should always be preferred" from within the package? "Prefer: python2-foo" but within the spec? Unsatisfiable requirement for the empty package would be a good idea in any case, to make sure the empty packages don't sneak into the distribution and on people's computers. As usual, i'll be glad for all your input, answer questions, etc. etc. regards m.

5 years, 5 months

[opensuse-packaging] build.opensuse.org maintenance on sunday and monday

by Adrian Schröter

Hi, we reached again new load levels on OBS and need to split again our main backend servers. This will happen on coming sunday and will most likely continue on monday. What will be affected exactly? * build.opensuse.org will stay and reachable * all content on download.opensuse.org will stay * source changes, requests will remain work * schedulers for main projects will get stopped. => new builds will not start, except for home:* and openSUSE staging projects. The builds will get triggered automatically when we boot the schedulers again. * projects outside of openSUSE and home namespace may show an old build state for some time until the final sync has finished. * home:* and openSUSE Staging projects will remain to work all the time, including building and publishing. The reward will be more IO throughput later one, which means faster scheduling and publishing :) -- Adrian Schroeter email: adrian(a)suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 5 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging December 2016