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,
recently there have been a few updates of package to use %license for
the license files. And this seems triggering the build failures for
SLE12.
How would we cure this? Fiddling with some prjconf stuff?
thanks,
Takashi
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi packagers :) ,
I have these two packages which have the same source. I've seen
sometimes we have a package foo with 2 spec files, foo.spec and
bar.spec, and then we have another package, bar, which is a link to foo.
This way, both share the same source.
I tried to do that, but when I submitted (osc sr) foo and bar to another
project, the link was lost, and instead I had two independent packages
with a copy of the same source.
Is there a way to keep the link? I tried the "--update-link" option but
didn't make a difference.
Thanks in advance
jordi
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello!
Here is package lsyncd, with very old bug-report:
https://bugzilla.opensuse.org/show_bug.cgi?id=975118 of annoying bug.
While maintainer is off (no replies in bz, no replies on emails), here
is the question: who can check and accept SR to bring fix for package
to openSUSE's users?
Thanks for your help!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello folks,
I submitted a couple of packages:
* stdman: agglomeration of the online C++ reference
en.cppreference.com in the form of man files, and
* cppreference-doc: An offline mirror of the C/C++ reference
en.cppreference.com in plain html, devhelp, and qhelp formats,
to what seemed like the most suitable devel project at the time:
Documentation [0]. However, these packages have now been rotting away
without review for about a month. If somebody on this list is on the
list of reviewers for that project, could you please review sr's 592066
[1] and 592291 [2] for me? Thank you very much.
For anyone else, do you have a suggestion for some other -- hopefully
more active -- devel project where these packages could go to? I had
planned for these two packages to end up in Leap:15.0; thanks to the
lack of response, that goal is pretty much dead and buried now :(
Thanks for any help, and best wishes.
[1] https://build.opensuse.org/project/show/Documentation
[1] https://build.opensuse.org/request/show/592066
[2] https://build.opensuse.org/request/show/592291
--
Atri Bhattacharya
Tue 24 Apr 22:44:56 CEST 2018
Sent from openSUSE Tumbleweed 20180420 on my laptop.
--
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 the maintainer of the package for Chicken Scheme, which currently resides
in devel:languages:misc. Since a while, it is now impossible to install both
chicken and mono-core, because they both provide binaries called csc and csi.
What is OpenSUSE's policy regarding conflicts like this? Some distributions
have renamed the mono-core binaries, since mono-core is the younger package,
thus prioritizing the older package. I could also imagine OpenSUSE
prioritizing the packages in the main repository, thus have mono-core take
over the names. In this case, what would be the renaming suggestion?
Best regards,
Daniel
Hello, All!
I'm trying to build 'package+package-devel' pair via OBS and there are
two problematic issues I have faced with.
[0] https://build.opensuse.org/package/show/home:k_mikhail/GOST34.11-2012
1) If to cut all fragments about package-devel off from spec-file ([1]
http://paste.opensuse.org/60953485), initial package gets built
successfully for all distros (CentOS, Fedora, Scientific, Mageia,
variable versions of SLE and openSUSE). Brilliant!
2) If to add fragments about package-devel back to spec-file ([2]
http://paste.opensuse.org/30292476), all RedHat-based distros handle
this new spec OK, instead of entire (open-)SUSE line, which diagnose:
=====
[ 69s] GOST34.11-2012-devel-0.12-32.1.x86_64.rpm: directories not
owned by a package:
[ 69s] - /usr/include/gost3411-2012
=====
although, e.g.:
mkdir -p %{buildroot}%{_mandir}/man1 and install is OK, but
mkdir -p %{buildroot}%{_includedir}/gost3411-2012 and install do not
give the result.
specs_diff: [3] http://paste.opensuse.org/88758762
I'm aware of %dir, but there is no need of it for [1] for some reason
and, for unknown reason, it is needed for [2]. That is also the
interesting question...
The second issue is for openSUSE_Leap_15.0 x86_64: blocked. Why?
Thanks for your hints and help!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi everyone,
due to the fact that vagrant changes its dependencies with each minor
release and normally requires older stuff than what is in Factory, we
set up a new packaging workflow for vagrant in Virtualization:vagrant.
vagrant's new version 2.0.2 is ready for submission, except that the
project is not a devel project for Factory. And I cannot find any hints
on how to get it set up as one.
Which documentation am I missing? I received no answers to the mails
sent so far, I guess because people are flooded by mails already.
Any hints?
Kind Regards,
Johannes
P.S.: 2.0.3 is also prepared, needs to be tested, though, before
submission. I also got multi-ruby-builds up my sleeve, that allow
building vagrant packages for SLES12 or Leap 42.3. Needs some tests and
thoughts, so not quite there yet.
--
Johannes Kastl
Linux Consultant & Trainer
Tel.: +49 (0) 151 2372 5802
Mail: kastl(a)b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hello!
I'm trying to build python-pytest-relaxed for SLE-12 in backports which
is required as a dependency for one of the tools we are using for the
public cloud stuff.
The build fails with RPM complaining about /usr/share/licenses being unowned:
[ 4s] ... running 01-check-debuginfo
[ 4s] ... testing for empty debuginfo packages
[ 4s] ... running 02-check-gcc-output
[ 4s] ... testing for serious compiler warnings
[ 4s] (using /usr/lib/build/checks-data/check_gcc_output)
[ 4s] (using /var/tmp/build-root/openSUSE_Backports_SLE-12-x86_64/.build.log)
[ 4s] ... running 03-check-binary-kernel-log
[ 4s] ... running 04-check-filelist
[ 4s] ... checking filelist
[ 4s] python-pytest-relaxed-1.0.0-0.noarch.rpm: directories not owned by a package:
[ 4s] - /usr/share/licenses
[ 4s] python3-pytest-relaxed-1.0.0-0.noarch.rpm: directories not owned by a package:
[ 4s] - /usr/share/licenses
[ 4s]
[ 4s] suse-laptop failed "build python-pytest-relaxed.spec" at Fri Dec 15 13:35:27 UTC 2017.
[ 4s]
Normally, this issue is fixed by installing the package which install this directory
into the chroot, either through a Preinstall directive in the project configuration
or by adding the package in question to Build-Depends in the spec file.
The directory /usr/share/licenses is provided by filesystem which I tried preinstalling
through the aforementioned mechanisms. However, I still keep running into the ownership
issue as shown above.
Does anyone have any idea what I am doing wrong?
Thanks,
Adrian
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
As from memory there are a number of people using d:l:p that maybe
subscribed to this list and not the opensuse-factory mailing list I
thought i'd post a link[1] to a thread about some changes happening in
d:l:p here as well as a heads up. Note that I deliberately didn't
forward / reply the email into this list as any possible discussion
should be contained to one thread on the factory list to avoid
fragmentation.
1. https://lists.opensuse.org/opensuse-factory/2018-04/msg00698.html
Cheers
--
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org