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.
I would like to open a discussion about use of systemd presets while
packaging.
Systemd preset files are preferred way how packages set the default
state of services. Preset files are located
in /usr/lib/systemd/system-preset directory. %service_add_post is aware
of presets, and if the package adds systemd service together with
presets, %service_add_post performs one-time set to the preset default
state.
Current policy is simple: All presets belongs to:
systemd-presets-branding-{product}
/usr/lib/systemd/system-preset/90-default-openSUSE.preset
and the default to disable all other:
/usr/lib/systemd/system-preset/99-default-disable.preset
It makes a lot of sense for packages with optional services, that should
be always on, like apache, network servers etc.
But I think that makes less sense for packages that are optional to
install, but it they are installed and not active, they are broken.
Especially if they are socket activated, the standby state means no more
than one socket opened by systemd.
I have two examples from last weeks:
uuidd: Optional socket activated util-linux daemon providing support for
UUIDs.
pcsc-lite pcscd: Smart Card daemon that is socket activated whenever
application attempts to use Smart Card PC/SC API. If it is not enabled,
Smart Card access does not work.
Note that it has a security implication:
Each package that installs default-on preset, should be audited by
security team. Security team would need to watch the whole directory,
not only a branding file.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz
Lihovarská 1060/12 tel: +49 911 7405384547
190 00 Praha 9 fax: +420 284 084 001
Czech Republic http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I hope i'm on the right ML with my problem. Please forgive me if not.
I need to write a specfile for use with openSUSE Build Service and have problems with the source fetching and versioning part.
The sources for the project are hosted at GitHub and i like to build a snapshot from the HEAD of the master branch.
So the package version should contain a (generated) numerical part which increments on each build and the (short) hash of the latest commit.
I believe that the tar_scm, set_version and recompress services are needed here. But i could not find a good tutorial or example for this.
Thanx for help,
Steffen
--
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Dear Ruby specialists,
For a while already, a few ruby packages in Factory/Tumbleweed are not
able to build (generally due to some packages changing to 'new'
packaging style, but not others).
The current list of packages is:
* rubygem-locale_rails
* rubygem-owncloud-admin
* rubygem-xmlhash
All of them being unresolvable.
not directly a ruby build failure, but still related:
puppet fails to resolve with: have choice for
rubygem(ruby:2.1.0:json_pure) >= 0 needed by rubygem-hiera:
ruby2.1-rubygem-json_pure-1_5 ruby2.1-rubygem-json_pure
It would be greatly appreciated to have those corrected soon.
Best regards
--
Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org>
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi All,
I want to make a modified version of plasma5-openSUSE package for 13.2, but
even the original unmodified package fails to build:
https://build.opensuse.org/package/live_build_log/home:TheIndifferent:brand…
Could anyone please explain me what is this about, what am I doing wrong and
how the same package is built in KDE:Frameworks5 repository without issues?
--
Regards,
Stas
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
13.1
zypp.conf: solver.onlyRequires = true
zypper.conf: installRecommends = no
# zypper -v in chromium
2 packages will be installed
package chromium will be installed
"recommended" package chromium-ffmpeg will be installed
(cancel)
# zypper al chromium-ffmpeg
# zypper -v in chromium
nothing provides chromium-dev needed by chromium-dev-ffmpeg
(cancel)
Why when "recommended" package installation is refused does chromium require
a -dev package or risk breaking yet another (unwanted) package?
--
"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
Hi,
Released distributions like openSUSE 13.2 do not have devel projects.
Therefore the process used for Factory where any submission has to pass
by the actual package maintainers does not work. This has caused some
surprises in the past.
Now we have a new review bot meant to avoid non-maintainer submissions.
The bot is now automatically added as reviewer for maintenance requests.
It checks whether the package was submitted by someone who is maintainer
of the Factory package. If the request was created by someone else the
bot adds the devel project/package as reviewer. The Factory maintainer¹
then has the chance to accept or decline the update.
Right now OBS has a bug that prevents it from sending mail notifications
for those new reviews. I hope it will be fixed soon. The submit request
are correctly listed on package maintainer's tasks lists on
build.opensue.org though.
cu
Ludwig
[1] only works for packages that are still in Factory of course.
The bot doesn't know what to do with packages that were dropped (or
renamed) from Factory so just let's them pass like before.
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, 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
Hi,
I'm trying to rebuild wine with a patch applied on top. I've updated
the spec file and rebuilt the rpm, both for x86_64 and i586, but I did
not get an -32bit RPM.
In the OBS repositories page [1] I see that the -32bit RPM is located
in the i586 repo, but I'm not sure how it's built.
I know I can branch the project and built it with the patch I need on
OBS, but it is slow and wasteful to do that just to build a patch.
Thanks,
Robert
[1]: https://build.opensuse.org/package/binaries/Emulators/wine?repository=openS…
--
http://robert.muntea.nu/
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
are bashisms in RPM scriptlets allowed?
Up to now I ignorantly assumed that bash is used for RPM scriptlets
so that bashisms in RPM scriptlets "just work".
But I got
https://build.opensuse.org/request/show/260498
By Googling for "bash rpm scriptlet site:opensuse.org"
I did not find an authoritative answer.
In particular neither
https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets
nor
https://en.opensuse.org/openSUSE:Specfile_guidelines
helps.
I found
http://lists.opensuse.org/opensuse-packaging/2010-03/msg00076.html
where comments therein seem to indicate that bash is o.k. for
shell scripts but to be on the safe side one should explicitly
require it via "#!/bin/bash" shebang but as far as I know
I cannot have a bash shebang in RPM scriptlets.
FYI:
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Default_Shell
reads:
"In Fedora, you can assume that the default shell (/bin/sh) is bash.
Thus, all scriptlets can safely assume that if they are running in
shell code, they are running within bash."
Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org