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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everyone,
sorry if this is an old hat, but I just stumbled upon it.
lxc changed the sources layout between 1.0.x and 1.1, and no longer
directly includes a configure file. So it has to be generated via
./autogen.sh.
What's the right way to do this in a spec file? Just call the
autogen.sh script? Or is there a macro for it?
I found an older mail from Ludwig (and others), where %_configure is
being redefined to run autogen.sh
http://lists.opensuse.org/opensuse-packaging/2011-02/msg00032.html
Regards,
Johannes
- --
Having a 'non-smoking' section in a restaurant is like having a
'non-peeing' section in a pool.
(Robin Cowdrey)
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/
iEYEARECAAYFAlSGCLsACgkQzi3gQ/xETbIwhgCdG6lr0laxVh9Nx6S5PrY5T3kv
T70AoIaU6xzPExgSlKd7mteIPRMsyi2b
=iO+j
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Evening everybody,
is there a reason why the following is an error only on 13.1, and not
on 13.2?
> ERROR: /usr/sbin/rclxc is packaged in both lxc-libs and lxc, and
> the packages do not conflict
The package is here, and as you can see, it builds fine for
> https://build.opensuse.org/package/live_build_log/home:ojkastl_buildservice…
Is
>
this intentional? Or what am I missing?
(The solution is to exclude the link in the files section of the libs
package. And the error is gone on 13.1, too, and it builds fine. At
least locally)
Regards,
Johannes
- --
Working with Unix is like wrestling a worthy opponent. Working with
windows is like attacking a small whining child who is carrying a .38.
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/
iEYEARECAAYFAlSXEXsACgkQzi3gQ/xETbJ/dwCfeDA0SLYhtzuFE0A+7ZyxSROX
ckcAnRpp4CXQOAoN9jY6MEvrLkJExvbe
=cvzv
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I did not change anything other than updating the syslog-ng version
(3.6.1 to 3.6.2), but yesterday my syslog-ng package compiled on SLES
12, and today not any more. I get the following error:
Getting buildconfig from server and store to
/root/home:czanik:syslog-ng36/syslog-ng/.osc/_buildconfig-SLE_12-x86_64
buildinfo is broken... it says:
unresolvable: have choice for syslog needed by syslog-service: syslog-ng
rsyslog
Why do I get this error, and how can I resolve this?
As you can see, other platforms compile just fine:
https://build.opensuse.org/package/show/home:czanik:syslog-ng36/syslog-ng
Bye,
CzP
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello all,
I have (one of many) weird problems with Build Service. Here's the first one. :-)
I built this package:
https://build.opensuse.org/package/show/home:emendonca:branches:devel:langu…
Which has an _aggregate on another branched project and two packages:
<aggregatelist>
<aggregate project="home:emendonca:branches:devel:languages:perl">
<package>perl-Gnome2-Vte</package>
<package>perl-macros</package>
<repository target="SLE_11" source="SLE_11_SP3" />
</aggregate>
</aggregatelist>
The package perl-Gnome2-Vte has an aggregate on perl-macros:
<aggregatelist>
<aggregate project="home:emendonca:branches:devel:languages:perl">
<package>perl-macros</package>
<repository target="SLE_11" source="SLE_11_SP3" />
</aggregate>
</aggregatelist>
So the whole build dependency chain is: perl-macros -> perl-Gnome2-Vte -> pac-manager.
The whole thing works, and all the packages get built successfully. The webui indicates that the resulting packages were published... but they are nowhere to be found. I already tried deleting built binaries and triggering new rebuilds, but the result is always the same. Only the first package binary (perl-macros) gets published.
What am I doing wrong here?
Erico Mendonça
Dedicated Support Engineer
(Work)+55 (61) 8594-9557
(Main) +55 (11) 3345-3900
(Personal) +55 (61) 9115-3256
emendonca(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
Let's say I have a fork of one of the packages that comes with system core.
That fork is targeted for very special target audience or special use-cases,
so please no flaming on the topic of how wrong is it to do something like
that...
But, that fork consists of libs and devel packages, and every time update for
this package comes in main repository - it gets replaced with updated non-
forked version. Or someone installs lib from official version and devel from
forked version, which is again wrong.
What is the recommended way to force a pair of those packages to stay in the
system?
I can think of some ways to do it:
* add custom provides to the spec file and make devel version require certain
provider of lib. But that will only protect from installing incompatible
versions of devel and lib packages, but not from installing both of them.
* add synthetic package that will depend on first two, again by certain
custom providers. This means that update will not be installed because
other package has a dependency for that provider. But yast update will
complain every time about that, and yes that does not sound very good.
* bump a version to 99.%{version}, to make it the newest existing provider
for both library and devel. But devel will have to require exactly the same
version.
So, for that use-case, should I use any of those workarounds, or there is
better way of doing it?
--
Regards,
Stas
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi to all!
How gcc49 can be used for oS 13.2? If it is required to build unresolvable
state will appear with message "conflict for provider of libgcc_s1 >=
4.9.0+r211729-2.1.7 needed by gcc49, (provider libgcc_s1-gcc49 is
conflicted by installed libgcc_s1)".
By the way gcc49 isn't my goal, I would like to make a clang build with
gcc 4.9' environment so any tips are welcomed.
--
Best regards,
Dmitriy DA(P).DarkneSS Perlow @ Linux x64
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All Factory and TW packages in packman start to fail because for some
reason rpmlint-Factory-strict-1.0-89.115 is now installed. This seems to
include a license check, which is most likely needed just in OBS and
IBS.
I wonder if this was a change in OBS, and if so how can I can avoid to
change a very large amount of spec files.
If this was caused by the update of the buildservice version in PMBS,
what is the knob to disable rpmlint-Factory-strict again?
http://lists.links2linux.de/pipermail/packman/2014-December/013353.html
Thanks,
Olaf
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
HI!
Is there a comprehensible list/table of SuSE version macros usable in .spec
files and some hints how they should be used?
I'm having a hard time to distinguish SLES 11SP3, SLES12 and openSUSE 13.1+ to
set right dependencies.
Ciao, Michael.