Hello all,
For use in libreoffice, chromium and others I've created macro that
should allow you to limit jobs based on some constraints you can set
later on in the spec to avoid OOM crashes.
The usage is pretty straight forward (Once it is accepted in
Tumbleweed):
===
BuildRequires: memory-constraints
%build
# require 2GB mem per thread
%limit_build -m 2000
make %{?_smp_mflags}
====
Here the _smp_mflags vaule for 8GB machine would be 4 while default is
number of cores (lets say 16)...
Both macros %jobs and %_smp_mflags are overriden as such the
integration should be really painless if you need to do something like
this.
Tom
Hello,
I am planning on updating libfuse from version 2.9.9 to
3.4.2. Currently, we have both libfuse2 (source fuse-2.9.9 or just
fuse) and libfuse3 (source fuse-3.4.2 or fuse3). It would be nice
if all users would move from libfuse2 to libfuse3.
What would be the best method to accomplish this:
1. Simply update fuse to fuse-3.4.2
2. Mark fuse 3.4.2 as obsoletes fuse < 3, and ship both for a
while
3. Any other method
I am afraid we will break depending applications if we choose 1,
though it should be compatible.
--
Goldwyn
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
So it seems that right now someone is in the process of doing some
upgrade work in KDE:Qt. Whoever it is has turned publishing off, which
usually is a good idea...
...but in this case it leads to hundreds of packages in KDE:Framework,
KDE:Extras, and KDE:Applications being rebuilt, and being published, and
because publishing of KDE:Qt is turned off, being unable to be installed
due to missing dependencies. The really bad part is, that *some*
packages from those newly built ones *will* be installed, and some
others will be downgraded to what's in the base distribution, leaving
people with a general mish mash of librariy versions and potentially
seriously broken desktops.
So ... can someone **please** turn publishing in KDE:Qt back on?
And for next time: whoever disables publishing in KDE:Qt for upgrading
it, disable publishing (and building) in KDE:Frameworks5,
KDE:Applications, and KDE:Extra.
Thank you.
*le sigh*
Mathias
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
here is my stupid question of the day:
spec-cleaner wants to move defines to the beginning of the spec file.
But I need it after Name and Version like that:
Name: hmcfgusb
Version: 0.103
%define tarball %{name}-%{version}.tar.gz
...
URL: https://git.zerfleddert.de/hmcfgusb/releases/%{tarball}
Source: %{tarball}
spec-cleaner wants to turn it around, but then it does not work:
%define tarball %{name}-%{version}.tar.gz
Name: hmcfgusb
Version: 0.103
...
Is it ok to ignore (in that case) spec-cleaner or is there a better
way to achieve that?
--
Mit freundlichen Gruessen,
Andreas Vetter
Stellv. IT-Bereichsmanager Fakultaet fuer Physik und Astronomie
Tel.: +49 (0)931 31-82264
Informations- und Kommunikationstechnik
Tel: +49 (0)931 31-85890
iuk(a)physik.uni-wuerzburg.de
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
The coreutils-testsuite runs best with a list of tools like valgrind,
gdb, python-inotify etc. but some of the tools are not available
on some platforms.
The problems is:
a) if I add a BuildRequires on platforms that don't have that package,
then the whole testsuite build on that platform fails.
b) Now I can add a guard around the BuildRequires per platform/OS version
manually, but:
b1) manually maintaining such a list is tedious,
b2) if the guards take out to many of BuildRequires, then the coverage
is not as good as it could be. This effect is transient if a package
gets available on a new platform in future.
As a packager, I'd love to just add the list of additional tools the
test may or may not use, and the build not failing if the package
is not available on that platform like:
BuildRecommends: valgrind
or
BuildSuggests: valgrind
Is there something automatic like this?
Thanks & have a nice day,
Berny
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
There are some packages that include python modules/packages that are
not installable via setup.py. Since they might not end up on the
normal python search path, python fails to find them and the build
looks 'broken'
For example, paraview (a package within the science project) installs
its shared libraries into its own /usr/lib64/paraview subdirectory.
The associated python3 packages get placed into
/usr/lib64/paraview/python3.x/site-packages/. Another project I
recently submitted places its python modules into
/usr/share/<package>/Python. Both of these cases end up with import
errors, and can be solved by fixing how the packages are installed.
Rather than moving the packages into the system site-packages
directory, I propose to simply throw a <package>.pth file into the
site directory for python 2 or 3 (or both if applicable) pointing to
the packages python modules.
Is there precedent regarding this issue?
Regards,
Chris
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
HI!
Are there any RPM macros one should use when packaging software
installed with a prefix /opt/foo?
Thanks in advance.
Ciao, Michael.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 3/10/19 10:05 PM, Chris Punches wrote:
> The RPMDB assures that not the filesystem paths. If you're using /opt
> you should still consider using the proper paths. As a consultant I
> often have this conversation with vendors providing software who don't
> know better and it's practically an epidemic. You want people to use
> the FHS to make good assumptions about where things are. I've heard all
> manner of arguments for why they have to do it this way and have never
> seen one be right.
Does a file conflict with OS-packaged libldap count
as sufficient argument?
Believe me. I'm not doing this for fun.
Ciao, Michael.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
It looks like the build results in the OSC web interface are not
displaying requires specified in the spec file, only
automatically-detected results.
For example, with alsa, it Requires: alsa-utils. But if you look at
the build results, that requirement is not listed:
https://build.opensuse.org/build/openSUSE:Factory/standard/x86_64/alsa/_log
This happens in every projects, package, and build target I have
checked. I am not sure if this is a bug or expected behavior, though.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org