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,
Trying to compile syslog-ng in my repo both for SLE_15 and
SLE_15_backports and ran into something interesting. I use the
following to detect SLES, and it works fine for the SLE_15 variant.
But for SLE_15_backports I get "nothing provides
riemann-c-client-devel"
# riemann does not compile on SLES
%if !0%{?is_opensuse}
%bcond_with riemann
%else
%bcond_without riemann
%endif
Any clues why the above does not work for backports?
Bye,
CzP
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
[Full quote to let the list gain from Rémi's insights]
Rémi Verschelde:
> @cunix: I'm not subscribed to the openSUSE packaging ML, so I'll let
> you forward my answer if it doesn't pass through moderation.
>
> Regarding unbundling fonts, I advise not to bother with it for the
> following reasons:
>
> - The main reason for unbundling fonts in distros is so that all
> packages can share the same fonts instead of bundling their own, thus
> reducing the install size on disk by avoiding duplication of data.
> There's no security risk, so it's much lower priority than unbundling
> libraries (especially as disk space is cheap).
>
> - One could argue that it allows to use the latest and greatest
> version of the fonts as packaged on the system instead of the one
> upstream bundles, but that also implies that we're using a version of
> the font that upstream did not test - unless the downstream packagers
> are very experienced with the software they're packaging, it could
> lead to some issues if the system font is not compatible with the
> application for whatever reason.
>
> In Godot's case more specifically:
>
> - Godot is designed to be self-contained and portable, so it doesn't
> rely on anything being installed on the system (apart from the most
> common system libraries). When packaging for a Linux distro, this is
> usually not what we want, so we can unbundle more libraries and fonts
> if needed and hardcore paths to the latter in the binary. It loses its
> portability but nobody is meant to take /usr/games/godot or
> /usr/bin/godot to send it to their friends. That said, it means that
> fonts are compiled into the binary by the buildsystem, so to unbundle
> them, you have to disable that and also add code to load system fonts
> (potentially adding a new dependency on fontconfig to Do It Right™).
> That's non negligible work, for a low priority policy IMO as mentioned
> above.
>
> - A more compelling reason for *not* unbundling fonts is that, unless
> you also build all export templates for all platforms (Linux
> (portable!), macOS, Windows, Android, iOS, HTML5, UWP) with the exact
> same fonts and provide those to openSUSE users, users of your package
> would have a different font when testing their game in the
> openSUSE-packaged editor and when shipping their games with the
> upstream-provided export templates. And that would be quite bad for
> the user experience. The same rationale applies to any kind of
> downstream patching of the editor that would introduce incompatibility
> with upstream-provided export templates. It *can* be done, but then
> you'd have to build and package all export templates too, which
> requires cross-compiling toolchains for the above-mentioned platforms
> and several hours of build for all those binaries.
>
> - Finally, Godot's fonts are hand-picked to ensure that we have all
> the symbols we want, especially the now-deprecated
> DroidSansFallback.ttf and DroidSansJapanese.ttf, which Google stopped
> distributing, but which is the best we could find to cover most Asian
> and Arabic symbols with a reasonably sized font (3.6 MB and 1.1 MB
> respectively).
Thank you so much for this comprehensive explanation Rémi!
You convinced me to leave the provided fonts untouched and i hope this
will be acceptable for Factory.
> 2018-08-29 1:18 GMT+02:00 cunix <cunix(a)gmx.net>:
>> Ludwig Nussel:
>> [...]
>>>>> Anyways, as you can see in modules/openssl/stream_peer_openssl.cpp
>>>>> there even is a commented call to SSL_CTX_load_verify_locations()
>>>>> "for testing". Pretty close. Replace that with a call to
>>>>> SSL_CTX_set_default_verify_paths(), reduce the built in bundle to
>>>>> not contain any certs at all and you are done. godot will then rely on
>>>>> openssl to read the system wide cert store.
>> [...]
>>> Well, explaion the issue upstream and ask them to help with the actual
>>> code :-)
>>
>> Thank you again very much for holding my hand Ludwig!
>>
>> After some experiments i implemented your suggestion in one patch and
>> added a second one to wrap a build option around it [1].
>> The bundled certs are removed in the spec file.
>> Does this reflect your ideas?
>>
>> At least after local compiling that seems to work but we have to test an
>> obs version more in depth.
>>
>> Because there might be consequences from this patch I'm not aware of or
>> certificates might be in use in other parts of Godot that aren't covered
>> by this solution, i don't feel really comfortable taking full
>> responsibility for it.
>> Rémi, do you want to comment? Please ;)
>
> The certificates bundle is mainly used for the Asset Library, to
> connect to https://godotengine.org/asset-library,
> so if that works with [1], that seems good to me.
I tried to connect to the Asset Library from within a patched Godot
after deleting the bundled certificates during build, once with a build
where "system certificates" was enabled (a) and once disabled (b).
The system was configured to only trust the "DST Root CA X3" root CA for
the "Let's Encrypt" intermediate CA.
(a) showed content, (b) didn't.
> Before merging it upstream, we'll likely want to make sure that it
> works reliably on all distros, and also on other platforms.
Hopefully that can be tested automatically in some way? Access to other
platforms i don't have.
> For the reference, Godot's certs bundle is also derived from the
> Mozilla certs data like most distros ship. But it's indeed synced
> manually so it can get outdated and require a rebuild against a new
> version, so an option to use the system one would be nice to have.
Yes.
In my opinion a major reason for openSUSE preferring to have this option
is, that this will reflect the configuration of a user's system
dynamically and isn't limited to the default trust settings of neither
Mozilla nor the (openSUSE) Distribution.
>> Whether this will survive the switch to mbedtls and if this is something
>> upstream might be interested in, I'm not sure but future will tell.
>
> Should be quite similar for mbedTLS. For upstream reviews, it would be
> better to start with a patch against the master branch (thus mbedTLS),
> and only then another one for the 3.0 branch (OpenSSL) once the former
> is approved.
I might look into this because we would have to do it for version 3.1
anyhow but don't want to promise anything right now.
If Godot is accepted for Factory the incentive will probably increase ;)
>> [...]
>>
>> [1] The two diffs @
>> https://build.opensuse.org/package/show/home:cunix:branches:games:tools/god…
>>
>> cunix
>
> Librement,
>
> Rémi
Thank you again for this detailed help!
cunix
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Rémi Verschelde:
[...]
> I don't think there's much left that can be unbundled in a realistic way.
> As mentioned, I'm both the upstream maintainer and a RPM packager, and I'm
> very familiar with unbundling policies.
While Max and me continue trying to package Godot in a form acceptable
for Factory, a few other questions arose, i hope Godot experts and
Factory policy interpreters can help us with.
Please correct me if my assumption is false, that Godot currently isn't
able to consider certificates at run time with trust settings determined
from the users machine to verify server certificates used for transport
encryption.
Instead, Godot uses a static list of trusted certificates, hardwired
during build. This list is bundled in the Godot source code.
While there is no explicit option to unbundle these trusted roots, we
were able to replace the Godot "bundle" with an openSUSE "bundle" [1],
derived from the "ca-certificates-mozilla" package.
This way i expect the Godot package to get rebuild automatically on obs,
if "ca-certificates-mozilla" gets some sort of update.
Questions are:
1. Is such a "replacement" enough and acceptable for Tumbleweed
inclusion, or is it undesired and a reason to "decline"?
2. Is this "unbundling" or should we still include a
"Provides bundled(ca-certificates-mozilla)"
in the spec file?
3. Is it perhaps unacceptable from a security point of view to have a
package in the openSUSE distribution, that doesn't use the users system
trust settings but is configured to always rely on the openSUSE defaults?
(Firefox does something similar but offers a UI to change them).
4. Should we take the same approach for some other parts of Godot?
For example it might be possible to replace the bundled fonts with their
openSUSE counterparts. This will be static as well and not using
installed fonts dynamically as far as the fonts in /thirdparty/fonts are
concerned.
[...]
cunix
[1] around line 130 of
https://build.opensuse.org/package/view_file/home:cunix:branches:games:tool…
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi packagers,
Stefan observed that in d:l:p no Leap repositories are
available anymore. There are Arm, PowerPC, zSystems, and Tumbleweed.
Are there any reasons why they completely vanished? Can the Leap repos
be readded again? I think, a lot of other repositories depend on it. :)
(Please keep Stefan in CC)
Thanks!
--
Gruß/Regards,
Thomas Schraitle
----------------------------------------------------------------------
SUSE LINUX GmbH (o<
Maxfeldstrasse 5 /\\ Documentation Specialist
90409 Nuernberg, Germany _\_v http://www.suse.comhttp://lizards.opensuse.org/author/thomas-schraitle/
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, 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
Greetings,
when I try to install trac[0] on openSUSE Leap 15.0, I receive the
following error:
------------------------------ 8< ------------------------------
# zypper in --dry-run trac
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Problem: nothing provides python-pygments needed by trac-1.2.2-lp150.1.2.noarch
Solution 1: do not install trac-1.2.2-lp150.1.2.noarch
Solution 2: break trac-1.2.2-lp150.1.2.noarch by ignoring some of its
dependencies
Choose from above solutions by number or cancel [1/2/c] (c):
------------------------------ >8 ------------------------------
This is strange, because python-pygments should be available from the
oS 15.0 base repo (as the spec[1] provides the exact spelling trac
requires[2]). However, when I use OBS to display the provides of the
built RPM, the provides is missing[3]. How come? Is this an OBS issue
or am I misunderstanding something? What can I do?
[0]: https://build.opensuse.org/package/show/devel%3Atools%3Ascm/trac
[1]: https://build.opensuse.org/package/view_file/openSUSE:Leap:15.0/python-Pygm…
(line 37)
[2]: https://build.opensuse.org/package/binary/devel:tools:scm/trac/openSUSE_Lea…
[3]: https://build.opensuse.org/package/binary/openSUSE:Leap:15.0/python-Pygment…
--
Kind regards
Christopher 'm4z' Holm / 686f6c6d
"We must respect the other fellow's religion, but only in the sense
and to the extent that we respect his theory that his wife is
beautiful and his children smart." --H. L. Mencken
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Is there a way to manually run repo-checker on a package or
repository? Specifically, I want to run the check to see if the built
packages are installable. I think I fixed such an issue but I want to
check it before I submit it.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I have a kernel module I maintain in the hardware project. From time to time I
get the following comment from the repo checker:
> Repo Checker wrote in package hardware/hdjmod:
>
> The version of this package in openSUSE:Factory has installation issues and
may not be installable:
>
> can't install hdjmod-kmp-default-1.28_k4.17.3_1-24.3.i586:
> nothing provides kernel-uname-r = 4.17.3-1-default needed by hdjmod-kmp-
default-1.28_k4.17.3_1-24.3.i586
> (we have kernel-default-base-4.17.4-1.4.i586)
> (we have kernel-default-4.17.4-1.4.i586)
>
> can't install hdjmod-kmp-pae-1.28_k4.17.3_1-24.3.i586:
> nothing provides kernel-pae needed by hdjmod-kmp-
pae-1.28_k4.17.3_1-24.3.i586
> nothing provides kernel-uname-r = 4.17.3-1-pae needed by hdjmod-kmp-
pae-1.28_k4.17.3_1-24.3.i586
> (we have kernel-default-base-4.17.4-1.4.i586)
> (we have kernel-default-4.17.4-1.4.i586)
TBH, it is completely unclear to me weather this is some transient error
caused by new kernel builds or an actual problem, and repo checker not being
locally runnable doesn't help the problem [1].
The problem does not show for x86_64 and the package is completely based on
the standard process for building kernel packages on OBS [2]. Is there
anything obvious I might be doing wrong? Any hints on what I could do to lock
in the the underlying issue?
Kind Regards,
Matthias
[1]: https://github.com/openSUSE/openSUSE-release-tools/issues/1210
[2]: https://www.suse.com/c/using-opensuse-build-service-create-and-distribute-k…
--
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
Hi All,
How do I go about making GCC7 available for SLES12 in OBS? Outside OBS
I just add the Toolchain repo, but it doesn't appear to be
available.The application I'm trying to package requires c++17, hence
the need.
Thanks!
--
Later,
Darin
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
where can i read about the reason of changes in structure of
devel:languages:python and the new devel:languages:python:backports?
Regards
Eric
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org