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
Hi all,
I am maintainer of Elinks web browser. I consider dropping it from Factory
and in a second time from network/elinks because :
* it has not received real updates from upstream for more than one year and
a half [0]
* I could not get in touch with any of the upstream developers
* the project web page states that the last release is a pre release done in
2012 [1]
* its bug tracking system is down [2] as well the mailing list [3]
If anyone has really good reasons why I should not drop it or is interested
in taking over maintainership, let me know, otherwise I will wait until
the weekend and make a drop request.
Regards,
[0] https://repo.or.cz/elinks.git/shortlog
[1] http://elinks.cz/
[2] http://bugzilla.elinks.cz/
[3] http://linuxfromscratch.org/mailman/listinfo/elinks-dev/
--
Sébastien Poher
--
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 package the newest ethereum-cpp version.
It requires libjsonrpc-cpp version 0.7.0. The package that is already
available provides version 1.1.1. Thankfully, libjsonrpc-cpp0 follows
good practice of building shared libraries with proper versioning.
I created a new package libjsonrpc-cpp0, that provides the older
version. Now both packages create libjsonrpc-cpp-devel package, but with
different versions. (AFAIK this is the proper way of packaging multiple
library versions, if header files sits in the same place)
You can find all my packages at
https://build.opensuse.org/project/show/home:etamPL:branches:network:crypto…
The problem I have now, is that ethereum-cpp does not build, because it
says "nothing provides pkgconfig(libjsonrpccpp-client) = 0.7.0". But if
I look into libjsonrpc-cpp-devel-0.7.0-1.1.x86_64.rpm file, into what it
provides, there is exactly "pkgconfig(libjsonrpccpp-client) = 0.7.0".
Am I doing something wrong?
--
Adam Mizerski
Hi,
Leap 15.1 will enter it's beta phase soon. Time to review whether
15.1 has the right versions of your packages!
You can do that by either installing the current Alpha versions¹ or
by checking OBS².
Also, please have a look at your personal page in OBS and check for
open reviews³. (Semi)automated submissions from Factory need
maintainer review as usual. So in case you missed the notifications from
OBS please have a look if there are submissions that need your approval.
cu
Ludwig
[1] https://software.opensuse.org/
[2] https://build.opensuse.org/project/show/openSUSE:Leap:15.1
[3] https://build.opensuse.org/user/tasks
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I need help from a cmake expert.
I'm trying to update ethereum-cpp package to the latest version. It uses
Hunter (https://hunter.sh/) to download and compile dependencies. Of
course, to make it compile on build service I had to disable Hunter
(easy, just add -DHUNTER_ENABLED=OFF to cmake) and adjust all
find_package calls, to use system provided libraries.
And now I hit the wall. Some of required libraries (ethash, Snappy and
yaml-cpp) are built with cmake themselves and are providing cmake files
in /usr/lib64/cmake. As far as I understood cmake manual, they should be
used with "find_package(<name> CONFIG REQUIRED)". Cmake does not
complain about any missing libraries and in log linked below it shows
that it uses those provided files. But files generated in build
directory contain "<name>-NOTFOUND" values and build fails.
Here you can find my current work:
https://build.opensuse.org/package/show/home:etamPL:branches:network:crypto…
Here you can find log from running cmake with "--trace --debug-output":
http://susepaste.org/77797237
--
Adam Mizerski
Hi!
Amazon has recently created new C++ dependencies for their AWS SDK in C++,
those are aws-c-common, aws-c-event-stream and aws-checksums.
I am currently in the process of packaging aws-c-common as a shared library
package [1]. Unfortunately, I got stuck in the process with one strange
issue:
[ 18s] libaws-c-common1.0.0.x86_64: W: shlib-unversioned-lib libaws-c-common.so.0unstable
[ 18s] Your package matches the Shared Library Policy Naming Scheme but contains an
[ 18s] unversioned library. Therefore it is very unlikely that your package can be
[ 18s] installed in parallel to another version of this library package. Consider
[ 18s] moving unversioned parts into a runtime package.
[ 18s]
[ 18s] libaws-c-common1.0.0.x86_64: E: shlib-policy-name-error (Badness: 10000) libaws-c-common0unstable
[ 18s] Your package contains a single shared library but is not named after its
[ 18s] SONAME.
The thing is that the actual packages don't contain the symbolic link in question:
suse-laptop:/var/tmp/build-root/openSUSE_Factory-x86_64/home/abuild/rpmbuild/RPMS/x86_64 # rpm -ql *rpm |grep unstable
suse-laptop:/var/tmp/build-root/openSUSE_Factory-x86_64/home/abuild/rpmbuild/RPMS/x86_64 #
Yet rpmlint is complaining. Anyone has got any idea?
Adrian
> [1] https://build.opensuse.org/package/show/home:glaubitz:branches:devel:librar…
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I recently looked into updating the freemind package, as it is both, severly
outdated and doesn't build on versions newer Leap 42. However, I ran into
somewhat of a road block as upstream switch from a classic Ant build to using
Gradle [1]. Is there any other package in openSUSE using Gradle? I searched
the Wiki for documentation on how to package software that uses Gradle but
sadly failed to find anything.
In case of Freemind there is the additional problem that the package assumes
Gradle to be present in the system. However, openSUSE doesn't package it. I
think this is on purpose, as some helpers are packaged and the recommended way
to use Gradle anyhow is to have the Gradle Wrapper [2] in the source code.
Yet, I fear that, even if I shipped the Gradle Wrapper as an additional
source, this would not work as the Gradle Wrapper will attempt to pull Gradle
from the internet.
Do you have any recommendation as to how to proceed? I would hate to have to
tarball-install this to my wife's machine.
Kind Regards,
Matthias
[1]: https://gradle.org/
[2]: https://docs.gradle.org/5.1.1/userguide/gradle_wrapper.html
--
Dr. Matthias Bach
www.marix.org
„Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig
über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
Hello,
i have a question to packaging.
Problem is. I have a dir or file which is under a directory from other
package.
I can now BuildRequires: OtherPackage OR i can include %dir in spec.
Example:
New file foo is under /srv/www/htdocs/newfile.
/srv/www/htdocs belongs to package apache2.
And newfile belongs to new package.
In spec i can now insert BuildRequires: apache2
OR
I insert %dir /srv/www/htdocs
(It's only an example)
I prefered BuildRequires because the dir /srv/www/htdocs belongs to apache,
not to newpackage.
But what is the preferred solution?
What is the right way for openSUSE packaging style guides.
I hope someone from openSUSE itself can help me.
Sorry. I want not the opinion or surmise from 'normal' packager.
I want a answer from top. A answer if it exists a standard from SUSE self.
I hope you understand what i want. :-)
Regards
Eric
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
Many packages split off translations into a -lang subpackage. It's
optional so the common way to package this is that the main package
recommends the -lang package:
$ rpm -q --recommends bash
bash-doc = 4.4
bash-lang = 4.4
By default however that means the -lang packages are installed always,
no matter whether the -lang package actually provides translations for
the system's language.
At the same time the dependency solver recognizes special locale()
provides so it knows when packages are locale specific:
$ rpm -q --provides ipa-pmincho-fonts|grep locale
locale(ja)
So in case no other package pulls in ipa-pmincho-fonts, it would still
get installed if the system is installed in Japanese.
There's also a variant that associates the locale specific package
with another package:
$ rpm -q --provides libreoffice-l10n-de|grep locale
locale(libreoffice:de)
Ie that one gets installed on a German system if libreoffice gets
installed too.
Furthermore we use %find_lang to tag all translation files with
their locale already:
$ rpm -q --qf '[%{filelangs} %{filenames}\n]' bash-lang|head -3
bg /usr/share/locale/bg/LC_MESSAGES/bash.mo
ca /usr/share/locale/ca/LC_MESSAGES/bash.mo
cs /usr/share/locale/cs/LC_MESSAGES/bash.mo
[...]
However:
$ rpm -q --provides bash-lang
bash-lang = 4.4-lp150.8.3.1
bash-lang-all = 4.4
Surprise:
$ rpm -q --provides MozillaFirefox-translations-common|grep locale
locale(MozillaFirefox:ar;ca;cs;da;de;en_GB;el;es_AR;es_CL;es_ES;fi;fr;hu;it;ja;ko;nb_NO;nl;pl;pt_BR;pt_PT;ru;sv_SE;zh_CN;zh_TW)
Firefox does that manually though. Wouldn't it make sense to
automatically tag all -lang packages with locale() and get rid of
the recommends?
Since English normally doesn't have mo files, a consequence would
be that a system installed in English wouldn't pull in any -lang
packages. Ie would be smaller without requiring --no-recommends.
Any takers? :-)
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi, I created a new package for the use of blender in response to a bug
report.
Sorry for the impatience but I would appreciate it if someone could
accept sr#663570 and make me a maintainer of the package so that I can
send it and the OSL enabled blender to Factory.
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