openSUSE Packaging February 2017

packaging@lists.opensuse.org

53 participants
36 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

3 years, 10 months

[opensuse-packaging] python singlespec: how to convert your package

by jan matejek

Dear packagers, this is an overview of how singlespec works and how to use it for your package. First, some key concepts: * It will allow you to build Python 2 and Python 3 (and PyPy 3 in the future) package from a single spec file, with very little manual effort. This means that if you're maintaining a separate python3-something in d:l:py3, you can now switch over to the common python-something in d:l:py. * It is designed to work on specs called "python-something". There is some support for "python2-something" and "python3-something", but it is mostly untested. If your spec file name doesn't start with "python", don't even try. (Yet.) * (if you're building for Factory,) all your dependencies must be converted first. That's because the macros will BuildRequire "python2-things", which only exist for packages that are already converted. The devel:languages:python:singlespec already has basic packages, and not all of them will be in d:l:py immediately, so if you want to play now, build against this project. I'll also be accepting SRs into it. * In general, if you're unsure, please submit to d:l:py:singlespec first. Also examine linkdiffs of packages in d:l:py:singlespec to get an idea of how it can look like. https://build.opensuse.org/project/show/devel:languages:python:singlespec * Individual macros are documented on github https://github.com/openSUSE/python-rpm-macros * I'm working on an autoconverter that performs most of the following steps automatically. I intend to use it to convert most of d:l:py into d:l:py:singlespec:staging, and then review and submit packages one by one. So maybe if you wait, you can save yourself some work ;) Conversion steps: 0. If you want to build for anything other than Factory, you need to include compatibility shims. This definition of the %python_module macro goes on top of your spec: %{?!python_module:%define python_module() python-%1 python3-%1} and a buildrequire: BuildRequires: python-rpm-macros 1. Wrap all your "BuildRequires: python-something": BuildRequires: %{python_module something} Do not do this in Requires or any other fields. If you have a buildrequire that should only apply to one python, say, python-enum34 only for python 2, do not wrap it. 2. At the end of the spec preamble, before %description, place the macro: %python_subpackages on a line by itself 3. Replace "python setup.py build" with %python_build and "python setup.py install" with %python_install. These already contain the usual arguments (--prefix, --root), so usually you don't need to add any. If you configure CFLAGS or something like that, export them first: CFLAGS="-fwrapv" python setup.py build -> export CFLAGS="-fwrapv" %python_build If you are running any other commands based on python, use %python_exec. "python setup.py test" -> "%python_exec setup.py test" This works for usual test runners too: "nosetests" -> "%python_exec %{_bindir}/nosetests" 4. If you're doing something more complicated ... say, removing files from %python2_sitelib and %python3_sitelib, use %python_expand. "%python_expand rm -f %{$python_sitelib}/foo/undesirable.txt" Yes, that is "%$python_sitelib". Beware. If you put only "%python_sitelib", it will not work, because "%python_sitelib" gets expanded before %python_expand touches it. In general, after %python_expand, "$python" is replaced by all pythons even in macro names. If you need more lines, wrap in braces: %{python_expand firstline secondline $python thirdline} Note that the first line must not be empty. 5. change "%files" to "%files %{python_files}" If you have subpackages, say "%files foo", then change to "%files %{python_files foo}". 6. If some files are only in one python version, mark them as %python2_only or %python3_only in the filelist. If there's more of them, you can use %ifpython2 ... %endif If the entry in question is a __pycache__ directory, use %pycache_only or %ifpycache. 7. If you are using update-alternatives, remove them. Instead mark the executable as %python3_only: %python3_only %{_bindir}/yourbinary In most cases, we only need one version of the executable. If the purpose of the tool is, e.g., reading EXIF metadata, we don't care if python 2 or 3 reads them. (And the library files are still installed for both.) (If you are sure that you need executables for all python versions, look at what python-bottle does: https://build.opensuse.org/package/view_file/devel:languages:python:singles… note the installation inside %python_expand. Usually, packages don't install versioned executables by themselves, so you need to do it manually. If your package does, good for you.) 8. Take the time to enable automatic tests :) have a nice weekend m.

3 years, 11 months

[opensuse-packaging] Verbose builds enforcing

by Tomas Chvatal

Hello everyone, I've noticed lately that some new incoming packages have the verbose build disabled. This means we can see build log like follows: [ 225s] [build ZIP] UIConfig/modules/dbquery/ss [ 225s] [build ZIP] UIConfig/modules/dbquery/st [ 225s] [build ZIP] UIConfig/modules/dbquery/sv [ 225s] [build ZIP] UIConfig/modules/dbquery/ta [ 225s] [build ZIP] UIConfig/modules/dbquery/te [ 225s] [build ZIP] UIConfig/modules/dbquery/th Instead of the full gcc calls. I am well aware of that the logs look prettier but we have rpmlint and brp checks that validate all the calls to gcc and linker and ensure everything is correct. If one uses the silent calls like above it results in no verification being done. I would like to ask you to check your packages if they are 'silent' and either run make with V=1 parameter or pass to configure option ' --disable-silent-rules'. Thanks a bunch Tom

3 years, 12 months

[opensuse-packaging] Python single-spec: it's starting

by jan matejek

Dear packagers, another long e-mail from me :) today I started submitting singlespec packages to d:l:py, and from there to Factory. This will start from the dependency root, which means python-setuptools and python-six go first, then various things like pytest, mock, urllib3 and requests, and so on. This means several things for you, most important of which is: 1. renamed RPMs for Python 2 In Factory, all the generated rpms will be "python2-modname" instead of "python-modname". Each package will provide/obsolete "python-modname", so this should be completely transparent for builds and users alike. Currently released distributions will not be affected. When building old-style packages, you might run into problems such as: "have choice for python-six required by python-setuptools: python-six python2-six". For d:l:py, i will be resolving these with Prefer: configuration in prjconf, and I'll try to get the problematic packages into Factory asap (when "python-setuptools.rpm" disappears from Factory, this error goes away). Still, this will cause some build failures while the transition to new-style is ongoing. Wait it out -- or go ahead and convert your package to singlespec style :) 2. No more SLE11 support (for real this time) I will try to ensure that setuptools and six build for SLE11. This might very well fail (no noarch, no python3) and I won't care -- in d:l:py at least. In other packages, I will be actively removing SLE11 compatibility hacks as part of the conversion. IIUC, packages that are already built should remain available if build is disabled. So this only means that SLE11 will not get updates. As discussed some months ago, I am also turning off building SLE11 by default -- again, this should mean that current versions are still available but no new versions are built. Reenable your package if you want it in SLE11. If there is interest, we could develop a "python-rpm-macros-compat" package with workarounds for SLE11, maybe even implement noarch support. 3. d:l:python3 merge New-style packages build for python 2 and 3 at the same time. So devel:languages:python3 will be going away. During the transition, d:l:py is going to become the master repository, and we'll have to check that it has good versions of packages that are currently in d:l:py3. 4. non-python-* packages Packages that are not called "python-*" will not be affected for now. I'll be looking into them later. 4. bugs Inevitably, there will be problems. File them as bugs or send an e-mail (possibly as a reply to this one) regards m.

3 years, 12 months

[opensuse-packaging] [Python single-spec] %py3_incdir macro gone for Factory

by Hans-Peter Jansen

Hi Jan, now, that %py3_incdir is gone for Factory, how are packages like python3- persistent supposed to be build? persistent wants to install its header files in a python version specific include location, where the C parts of Btrees picks them up later on... except from python3-persistent.spec: %files devel %defattr(-,root,root,-) %if 0%{?suse_version} < 1230 %{_includedir} %else %dir /%py3_incdir/persistent /%py3_incdir/persistent/*.h %endif %python3_sitearch/persistent/*.h Build log: https://build.opensuse.org/package/live_build_log/devel:languages:python3/p… Cheers, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 12 months

[opensuse-packaging] sharedlib names for wxWidget variants

by Olaf Hering

The pkg wxsqlite3 adds the version of wxWidgets to its SONAME. This causes build failures because there is appearently no rpm macro for the used wxWidgets version. If the pkg name is hardcoded it will fail with old or upcoming wxWidgets versions. I wonder if wxsqlite3 or our packaging of wxWidgets is the culprit. Right now the subpkg is named "libwxcode_gtk2u_wxsqlite3-3_0-0", but it should be named "libwxcode_gtk2u_wxsqlite3-2_8-0" if built against wxWidgets-2.8. The SONAME looks like that, based on the m4 macro below: libwxcode_gtk2u_wxsqlite3-2.8.so.0()(64bit) libwxcode_gtk2u_wxsqlite3-3.0.so.0()(64bit) AC_DEFUN([WX_LIKE_LIBNAME], [ wx_temp="$2""_""$WX_PORT" dnl add the [u][d] string if test "$WX_UNICODE" = "1"; then wx_temp="$wx_temp""u" fi if test "$WX_DEBUG" = "1"; then wx_temp="$wx_temp""d" fi dnl complete the name of the lib wx_temp="$wx_temp""_""$3""-$WX_VERSION_MAJOR.$WX_VERSION_MINOR" dnl save it in the user's variable $1=$wx_temp ]) WX_LIKE_LIBNAME([WXSQLITE3_LIBNAME], [wxcode], [wxsqlite3]) How should this pkg deal with the SONAME? Remove the wxWidgets version and remove the ability that more than one wxWidgets version can be supported, or add code to the specile to decide at buildtime how the subpkg should be named? Thanks, Olaf

4 years

Re: [opensuse-packaging] %license macro

by Johannes Kastl

On 22.02.17 20:47 Ferdinand Thiessen wrote: > I do not use that path directly, I simply use > %license LICENSE.md > > As I would use > %doc LICENSE.md Aaaaah, now I understand you. So the %license macro is messing things up somehow. Sorry, without having the actual spec I could only guess... Johannes

4 years

[opensuse-packaging] %license macro

by Ferdinand Thiessen

Hi, my question: What is the consent on using the %license macro? I noticed this is available since Leap, but only works for 42.2 and newer. (42.1 does not know the "/usr/share/licenses" directory). Are packagers encouraged to use if for packages or should we still use %doc for licenses? I am personally use it for new packages with an "if 42.1 then doc". And I read the discussion in openSUSE-factory and I know the advantage of %license is that you can strip %doc from the package if not needed (e.g. use less space in containers...) and still ship the license (which is in most cases mandatory according to license terms). But I see rather few packages using %license. Regards, Ferdinand -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years

[opensuse-packaging] python-wxWidgets mismatch in Factory

by Olaf Hering

A package with the following buildrequires fails to build. Why is there a mismatch? What does "The library" mean, is it wxWidgets itself? It seems all pkgs build fine in Factory. BuildRequires: python-devel BuildRequires: python-wxGTK BuildRequires: python-wxWidgets BuildRequires: update-desktop-files BuildRequires: wxWidgets-devel ... [ 36s] [163/340] cumulate libwx_baseu-suse3-3.0.2-10.1 [ 39s] [181/340] cumulate libwx_baseu_net-suse3-3.0.2-10.1 [ 39s] [182/340] cumulate libwx_baseu_xml-suse3-3.0.2-10.1 [ 63s] [319/340] cumulate libwx_gtk2u_core-suse3-3.0.2-10.1 [ 63s] [321/340] cumulate libwx_gtk2u_ribbon-suse3-3.0.2-10.1 [ 63s] [322/340] cumulate libwx_gtk2u_stc-suse3-3.0.2-10.1 [ 64s] [323/340] cumulate libwx_gtk2u_html-suse3-3.0.2-10.1 [ 64s] [324/340] cumulate libwx_gtk2u_qa-suse3-3.0.2-10.1 [ 64s] [326/340] cumulate libwx_gtk2u_aui-suse3-3.0.2-10.1 [ 64s] [328/340] cumulate libwx_gtk2u_gl-suse3-3.0.2-10.1 [ 65s] [329/340] cumulate libwx_gtk2u_media-suse3-3.0.2-10.1 [ 65s] [330/340] cumulate libwx_gtk2u_adv-suse3-3.0.2-10.1 [ 65s] [332/340] cumulate libwx_gtk2u_propgrid-suse3-3.0.2-10.1 [ 66s] [335/340] cumulate libwx_gtk2u_richtext-suse3-3.0.2-10.1 [ 66s] [336/340] cumulate libwx_gtk2u_xrc-suse3-3.0.2-10.1 [ 66s] [338/340] cumulate libwx_gtk2u_webview-suse3-3.0.2-10.1 [ 66s] [339/340] cumulate python-wxWidgets-3_0-3.0.2.0-2.12 [ 67s] [340/340] cumulate wxWidgets-3_0-devel-3.0.2-10.1 ... [ 100s] + python src/compile [ 100s] Fatal Error: Mismatch between the program and library build versions detected. [ 100s] The library used 3.0 (wchar_t,compiler with C++ ABI 1002,STL containers,compatible with 2.8), [ 100s] and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1010,STL containers,compatible with 2.8). [ 100s] /var/tmp/rpm-tmp.54v83N: line 35: 6203 Aborted python src/compile ... Olaf

4 years

[opensuse-packaging] python .pyc packaging

by Bernhard M. Wiedemann

Via https://en.opensuse.org/openSUSE:Reproducible_Builds I found that when we build python packages like python-amqp or python-binplist it contains a .pyc file for every .py file and for every build these .pyc files differ, because they contain the timestamp of the corresponding source file and for some source files this is the time of build. http://rb.zq1.de/compare.factory-20170208/python-amqp.html#content http://rb.zq1.de/compare.factory-20170208/python-binplist.html#content I was wondering how to best get those to build bit-by-bit identical rpms. I assume, we want to keep the concept of .pyc files, since they provide some performance gain (e.g. I measured 'openstack --help' taking only 1.5 seconds with .pyc files versus 2.5 seconds without (on another machine it was 12 vs 13 seconds)) But why do we have to ship .pyc files as part of our binary rpms? They waste disk space and bandwidth for our mirrors and users. They could be created in a %post or %posttrans hook when installing the rpm (or do they need special build deps?) It might even be, that compiling them on the destination is faster than transferring and unpacking the LZMA compressed version. The less intrusive alternative approach would be to touch .py files to a constant older date (e.g. $SOURCE_DATE_EPOCH if set) before generating the .pyc files. What do you think which way to go? Ciao Bernhard M. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging February 2017