Morning all,
I need to separate one module from a build of a python package into a separate
package.
This is usually not a big act, e.g. in C-programs. Python packaging seems to
be different from that
What normally happens is that you have a file section with:
%files
[some more definitions]
%{python_sitelib}/*
Where the last command puts everything under /usr/lib/python3.x/....
Done.
After having defined a new package in the spec file I wanted to separate the
files:
%files -n %{name}-orthanc
%{python_sitelib}/health-orthanc*
-> This results in a 'file not found error':
[ 34s] /home/abuild/rpmbuild/BUILDROOT/gnuhealth-3.5-0.x86_64/health-
orthanc*
No surprise, as this is not the location for the module.
So, I've defined a variable to keep the path:
%define t_path $(ls -d /usr/lib/python3.* )/site-packages/trytond/modules
that expands nicely e.g. in the Installation section:
echo %{t_path}
[ 29s] ++ ls -d /usr/lib/python3.6
[ 29s] + echo /usr/lib/python3.6/site-packages/trytond/modules
[ 29s] /usr/lib/python3.6/site-packages/trytond/modules
but in the files section:
%files -n %{name}-orthanc
%{t_path}/health-orthanc*
[ 38s] Processing files: gnuhealth-orthanc-3.5-0.noarch
[ 38s] error: File must begin with "/": $(ls
[ 38s] error: File must begin with "/": -d
[ 38s] error: File must begin with "/": )/site-packages/trytond/modules/
health-orthanc*
At the moment I'm a bit stuck.
Anyone with a better idea or an example?
Thanks
Axel
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi, where do I report a bug in the macro that creates the value for
-flto=n which is greater than the reduced number of threads created by
%limit_build -m n causing link time crashes in gcc.
Thanks
Dave P
--
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 currently building a python 3 program, that will create a desktop file
entry. The samepackaging sequence as for the python 2.7 does - surprisingly -
not work.
What I do:
# menu-entry
desktop-file-install --dir %{buildroot}%{_datadir}/applications %
{name}.desktop
%suse_update_desktop_file %{name}
mkdir -p %{buildroot}%{_datadir}/pixmaps
cp tryton/data/pixmaps/tryton/gnuhealth-icon.png %{buildroot}%{_datadir}/
pixmaps/gnuhealth.png
That works *but* the rpm check moans about:
gnuhealth-client.noarch: E: hardlink-across-partition (Badness: 10000) /usr/
lib/python3.6/site-packages/tryton/data/pixmaps/tryton/gnuhealth-icon.png /
usr/share/pixmaps/gnuhealth.png
[ 12s] Your package contains two files that are apparently hardlinked and
that are
[ 12s] likely on different partitions. Installation of such an RPM will fail
due to
[ 12s] RPM being unable to unpack the hardlink. do not hardlink across the
first two
[ 12s] levels of a path, e.g. between /srv/ftp and /srv/www or /etc and /
usr.
This is kinda strange - cp is not ln, no?
Any ideas?
Cheers
Axel
PS:
<https://build.opensuse.org/package/show/Application:ERP:Tryton:5.0/gnuhealt…>
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
If you haven't seen or heard much about the /usr/etc proposal, that's
because we had to wait that the necessary basic changes were accepted
in Factory.
With today, we got two important packages released:
- filesystem contains /usr/etc
- rpmlint accepts /usr/etc
We are still missing rpm-config-SUSE for the %_distconfdir define.
I did also setup a wiki for best practices and the changes we make,
please see:
https://en.opensuse.org/openSUSE:Packaging_UsrEtc
Improvements, corrections, better ideas, etc. are always welcome!
And if you adjust your package, please document this in this list, too.
So that users have one place to find out what we changed, where to find
the configuration files today and what they need to modify.
I created a home project with first adjusted packages, too:
https://build.opensuse.org/project/show/home:kukuk:etc
All packages are tested on openSUSE MicroOS.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
Managing Director: Felix Imendoerffer (HRB 247165, AG München)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
While trying to upgrade syslog-ng in Base:system I ran into a strange
problem. It compiles fine even for the ancient SLES 12, but for SLES 12
SP2 and earlier package building fails with a strange error message:
[ 139s] ... running 03-check-binary-kernel-log
[ 139s] ... running 04-check-filelist
[ 139s] ... checking filelist
[ 139s] syslog-ng-3.23.1-167.1.x86_64.rpm: directories not owned by a package:
[ 139s] - /usr/share/licenses
[ 139s]
[ 139s] sheep83 failed "build syslog-ng.spec" at Tue Sep 3 15:40:47 UTC 2019.
Not that I expect anybody still using SP2 and earlier, but still would
love to see it all green. Is there a solution / workaround for this problem?
For complete logs, check:
https://build.opensuse.org/package/live_build_log/home:czanik:branches:Base…
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,
the SUSE security team wants to change part of our process in a way that will
affect (open)SUSE packagers. Several features in a package currently produce
rpmlint errors that ask packagers to submit the package for a review by the
security team. E.g.:
- Adding a setuid binary
- Changing polkit settings
This is described here:
https://en.opensuse.org/index.php?title=openSUSE:Package_security_guideline…
The current approach (error by rpmlint) has the drawback that this also
triggers in devel projects. So if you package something with a setuid binary
but don't intend to make this package part of (open)SUSE you will still see the
errors. You then either have to suppress them or we have to spend effort on
reviewing something that's not in an official distribution.
We want to change these errors into warnings without badness (first only in
Factory, but in short order also for openSUSE:* and SUSE:* too). You will still
see a warning that informs you that you need to go through a review if you want
it in an official distribution. This is then enforced by adding reviews for the
security team to each request made to an official distribution if these
warnings are present. Once the changes have been reviewed and whitelisted the
warnings will vanish.
The upside for you is that you can already use/test your packages in the devel
project without being blocked by build errors.
We hope to make the process faster and easier for everyone involved. Nothing
will change for you if:
- you don't need special permissions in you package
- you need special permissions and they were already checked by the
security team
If you see one of these warnings they describe what you need to do to get your
submits through without an additional review being added to the submit. We have
a constant flow of audit bugs, so please open you audit request as early as
possible so that we don't introduce a delay in your request while we review the
changes.
If you have any questions please ask away (please CC me) or contact
security(a)suse.de
Thanks,
Johannes for the SUSE security team
--
GPG Key E7C81FA0 EE16 6BCE AD56 E034 BFB3 3ADD 7BF7 29D5 E7C8 1FA0
Subkey fingerprint: 250F 43F5 F7CE 6F1E 9C59 4F95 BC27 DD9D 2CC4 FD66
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg
Geschäftsführer: Felix Imendörffer (HRB 247165, AG München)
Hello,
Which lines in .spec causes the following and how is it fixed so it builds.
Thanks Glenn
Project:
https://build.opensuse.org/package/view_file/home:doiggl/oracle-database-se…
Spec:
https://build.opensuse.org/package/view_file/home:doiggl/oracle-database-se…
Log:
https://build.opensuse.org/package/live_build_log/home:doiggl/oracle-databa…
running 06-check-installtest
[ 27s] ... testing for pre/postinstall scripts that are not idempotent
[ 27s] pre/postinstall/uninstall script of oracle-rdbms-server-11gR2-preinstall-1.0-34.1.x86_64.rpm modifies filelist!
[ 27s] filelist diff:
[ 27s] --- //.build_patchrpmcheck1 2019-09-03 06:57:42.616000000 +0000
[ 27s] +++ //.build_patchrpmcheck2 2019-09-03 06:57:42.644000000 +0000
[ 27s] @@ -24,3 +24,6 @@
[ 27s] +missing /etc/sysconfig/oracle-rdbms-server-11gR2-preinstall
[ 27s] +missing /etc/sysconfig/oracle-rdbms-server-11gR2-preinstall/oracle-rdbms-server-11gR2-preinstall-verify
[ 27s] +missing c /etc/sysconfig/oracle-rdbms-server-11gR2-preinstall/oracle-rdbms-server-11gR2-preinstall.param
[ 27s]
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
I'd like to propose adding /usr/libexec to the openSUSE FHS and
reverting the definition of %_libexecdir in rpm back to /usr/libexec
so that libexec content is installed there.
Currently, openSUSE overrides rpm to define %_libexecdir as /usr/lib,
which leads to pollution of the /usr/lib directory with executable
content as well as 64-bit content when there shouldn't be any. The
/usr/libexec has been in use on RH/Fedora and Mageia systems in the
Linux world, but has its origins in BSD and is still used today in
BSDs and variants (like Mac OS X). The usage of /usr/libexec for
libexec content has also been recognized by FHS with v3.0, released in
2015. In the Linux distribution landscape (that is, all major
families, not just RPM ones), /usr/libexec is in use on Red Hat,
Mandrake, Gentoo, and Slackware families.
This is a breaking change, as it means that as packages are rebuilt,
libexec content *should* migrate from /usr/lib to /usr/libexec. The
major advantage of migrating the libexec content is that it will make
openSUSE consistent with other major RPM-based Linux distributions,
and ease efforts in supporting SUSE distributions along with Red Hat
ones by removing the need for hacks and tweaks to support two
different hierarchies. This simplifies the portability headaches in
supporting both distribution families, and makes it easier for
applications that were originally aimed for RHEL/CentOS to run on
SLE/openSUSE Leap.
This change would be done in three stages:
1. Make the change to the filesystem package to add /usr/libexec to
the hierarchy.
2. Add /usr/libexec to allowed prefixes in rpmlint-checks and remove
spec-cleaner rule that assumes /usr/lib == %_libexecdir.
3. Make the change to the rpm package to set %_libexecdir back to
/usr/libexec. This one will cause a fair bit of work to fix packages
that do the wrong thing one way or another with %_libexecdir.
What do you all think?
Best regards,
Neal
--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org