openSUSE Packaging August 2018

packaging@lists.opensuse.org

34 participants
18 discussions

[opensuse-packaging] New macro to limit resources allocation per thread
by Tomas Chvatal 23 Aug '19

23 Aug '19

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

7 12

[opensuse-packaging] SLE_15 vs SLE_15_backports
by Peter Czanik 06 Sep '18

06 Sep '18

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

4 5

Re: [opensuse-packaging] Packaging Godot
by cunix 29 Aug '18

29 Aug '18

[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

1 0

[opensuse-packaging] Packaging Godot
by cunix 29 Aug '18

29 Aug '18

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

4 8

[opensuse-packaging] No Leap repos anymore in devel:languages:python?
by Thomas Schraitle 29 Aug '18

29 Aug '18

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.com http://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

4 9

[opensuse-packaging] trac requires python-pygments, which cannot be found on oS Leap 15.0
by 686f6c6d 28 Aug '18

28 Aug '18

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

2 2

[opensuse-packaging] Manually run repo-checker
by Todd Rme 24 Aug '18

24 Aug '18

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

3 3

[opensuse-packaging] Repo Checker notifications for i586 kernel modules
by Matthias Bach 24 Aug '18

24 Aug '18

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

2 1

[opensuse-packaging] BuildRequires GCC7 for SLES12
by Darin Perusich 24 Aug '18

24 Aug '18

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

3 3

[opensuse-packaging] Reason of changes in devel:python structure
by Eric Schirra 23 Aug '18

23 Aug '18

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

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging August 2018