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
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.
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
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.
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
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
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
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
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#contenthttp://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