July 2018 - openSUSE Packaging - openSUSE Mailing Lists

[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] 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] Overriding a "Requires" in a rubygem package
by Johannes Kastl 30 Jul '18

30 Jul '18

Hi guys, I am trying to get vagrant-libvirt installable via RPM (so that it is found by vagrant and does not need to be installed via 'vagrant plugin'). Currently, Tumbleweed contains 2.1.0 of rubygem-fog-core, while rubygem-vagrant-libvirt requires 1.43. So, I tried to override this and try if everything falls apart, rather than create another versioned rubygem and get that into Factory... But it does not work. https://build.opensuse.org/package/show/home:ojkastl_buildservice:branches:… I added a patch 0001-change-dependency-for-fog-core-to-2.1.0.patch that changes the versions in the gemspec file, and added it to the spec via the gem2rpm.yml: :patches: 0001-change-dependency-for-fog-core-to-2.1.0.patch: -p1 This resulted in the following lines in the spec file: %prep %gem_unpack %patch0 -p1 find -type f -print0 | xargs -0 touch -r %{S:0} %gem_build But still somehow 1.43 ends up being required: ######################################################################## sudo zypper in ruby2.5-rubygem-vagrant-libvirt-0.0.43-4.1 Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides rubygem(ruby:2.5.0:fog-core:1.43) >= 1.43 needed by ruby2.5-rubygem-vagrant-libvirt-0.0.43-4.1.x86_64 ######################################################################## Is there some mechanism that I am overlooking, that dynamically generates the dependencies and does not respect the gemspec file containing my changes? Thanks in advance. Kind Regards, Johannes -- 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

2 3

Re: [opensuse-packaging] Packaging Godot
by cunix 30 Jul '18

30 Jul '18

Rémi Verschelde: [...] > The idea is that those thirdparty projects are not necessarily libraries > per se, or at least not usually found packaged as shared or static > libraries. > > They're placed in the thirdparty golder because they weren't written by > Godot, but for most of them they're not particularly meant to be unbundle > more than Godot's own code would be. > > Some of them *could* likely be turned into shared libraries packaged system > wide, but this may imply forking those thirdparty projects to implement > proper libification, as they're often not active anymore (e.g. > jpeg-compressor, or mikktspace, or hq*x). > > If you want to check in depth, the provenance of all files is documented in > thirdparty/README.md. Thank you very much for this information. The thirdparty/README.md is shipped in our package. I'll propose to mirror in the openSUSE spec what you did for Fedora. Thanks for offering to use the result of your work! Your remarks from up- and downstream are hopefully a good reference for our distribution maintainers to not require more unbundling than what Godot offers as options in the build script. 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

Re: [opensuse-packaging] Packaging Godot
by Neal Gompa 29 Jul '18

29 Jul '18

On Sat, Jul 28, 2018 at 12:03 PM Rémi Verschelde <rverschelde(a)gmail.com> wrote: > > 2018-07-28 17:53 GMT+02:00 Neal Gompa <ngompa13(a)gmail.com>: > > On Sat, Jul 28, 2018 at 11:51 AM Max Mitschke <maxmitschke(a)fastmail.com> wrote: > >> > >> Howdy, > >> > >> Can someone advise me on how best to package the Godot game engine? > >> > >> The game engine includes a fair amount of modified third-party libraries in the source repo. To give an example, the ENET library has been modified to include IPv6 support and for the library to be usable by Godot’s socket implementation. A lot of other small libraries have been modified and clearly marked with "// -- GODOT —“ comments within the code. > >> > >> Another maintainer for Godot has already begun the process of including some openSUSE libraries. But I believe openSUSE requires that all third-party library code be packaged separately. The current status of the Godot package can be found at the second link which is listed below. > >> > > > > Godot is packaged by one of the developers (Rémi Verschelde) for > > Fedora and Mageia. You may wish to consider his spec files for > > guidance on how to package for openSUSE: > > > > Fedora: https://src.fedoraproject.org/rpms/godot/blob/master/f/godot.spec > > Mageia: http://svnweb.mageia.org/packages/cauldron/godot/current/SPECS/godot.spec?v… > > Indeed, I'm the upstream project manager and also a Linux packager, so > I'd suggest this to be the "right" way to package Godot (not that > there's only one good way though, but this one should be good). > > You can reuse my Fedora/Mageia spec fully or in part, as far as I'm > concerned it's public domain (strictly speaking I believe the Fedora > one would be MIT-licensed by default). > > I'll gladly answer questions or review your spec if needed - do note > that I'll be AFK for the next 10 days though. > As I was the one that reviewed the Fedora package for merge into the distribution, feel free to ask me as well, given Rémi's leave for the next week or so. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

Re: [opensuse-packaging] Packaging Godot
by Jan Engelhardt 29 Jul '18

29 Jul '18

On Sunday 2018-07-29 19:34, Rémi Verschelde wrote: >I know at least that Bullet could be unbundled if you package a git snapshot systemwide, but most distros reasonably package only the >current stable, which is too old for Godot. Not a problem: if you need a newer version, you're getting it. Having multiple versions is not an issue in openSUSE. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 3

[opensuse-packaging] Packaging Godot
by Max Mitschke 28 Jul '18

28 Jul '18

Howdy, Can someone advise me on how best to package the Godot game engine? The game engine includes a fair amount of modified third-party libraries in the source repo. To give an example, the ENET library has been modified to include IPv6 support and for the library to be usable by Godot’s socket implementation. A lot of other small libraries have been modified and clearly marked with "// -- GODOT —“ comments within the code. Another maintainer for Godot has already begun the process of including some openSUSE libraries. But I believe openSUSE requires that all third-party library code be packaged separately. The current status of the Godot package can be found at the second link which is listed below. Links: 1. https://github.com/godotengine/godot/tree/master/thirdparty 2. https://build.opensuse.org/package/show/games:tools/godot Thanks! Max Mitschke -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] How to directly branch an entire project and file a request for it.
by Shikhar Jaiswal 27 Jul '18

27 Jul '18

Hi, I wanted to branch all the packages (from a remote project channel) to my remote subproject in OBS. Furthermore, I wish to file a single request for all the packages that I have branched. Is there a simple way of achieving this? Regards, Shikhar -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] Zypper prefers python-pycrypto
by Sean Marlow 24 Jul '18

24 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi fellow packagers, I have a python cli app that requires Libcloud [1]. To use the GCE driver in Libcloud pycrypto is required. Instead of using the the un- maintained package I added pycryptodome as the requirement [2]. Unfortunately when doing a test install on a Leap15 instance Zypper decides that the requirement should actually be python3-pycrypto instead of python3-pycryptodome. There is no other requirement in the dependency tree for pycrypto and both packages are available from Leap:OSS repo. python3-pycrypto == 2.6.1-lp150.1.8 python3-pycryptodome == 3.4.7-lp150.1.3 Any ideas why Zypper is attempting to install pycrypto even though it's not in the dependency tree instead of the preferred package which is explicitly required? [1] https://build.opensuse.org/package/view_file/openSUSE:Leap:15.0/pyt hon-apache-libcloud/python-apache-libcloud.spec?expand=1 [2] https://build.opensuse.org/package/view_file/home:seanmarlow:branch es:Cloud:Tools/python3-ipa/python3-ipa.spec?expand=1 Thanks, - -- Sean Marlow Public Cloud Developer sean.marlow(a)suse.com -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEqA16xWoe2L38VgYCJ30GzZDdUEsFAltXVJIACgkQJ30GzZDd UEsCvw//U5S6q2uBV/rwi5GByIrPsW5DnzSk7oCHy7FHmnX7HS2TsddDkRlj2w3B huyhtuo4VXgfIc8tf/8MOyCbSEwmPYX3q9pViAqRGgBOotU+dnOmrQU4CMX/rzsd rJOcT6RcMjAbbchFrUGwMet2jXWYMLvWw391hzPbYoJMn1ocdVtpEITd5XgN5gOs DZhhEtZqtRGMsMgPxgd/OsCoLHXSFtLK/GuwD9SAleKB8DCS+hFCdTr2UBmDr6xN +ky2yfC5v/KXffcGGB+8Pwqw/X6ZG29XOHP2AVBeSy0SpOjFe4EJeP5daOanYXlO PEnq2gfUZCZCJPzynxg6E9IVAGda5R2HJ8pVuBknD21VL4pAq1CJetmlkUq1LVor tixoDk1dVNCw3FqreIl6KBO3TUcKNeSd/E2hGkRC/87AHQk/5rHOazXxsopZLLjb AEuCJX7Pr4sWYiNY9MXLi1Vvn+/CODCQ/eFFERWgdCNpEr6VuWfCs1CXSF1lL7g5 JQTSEA0JyiWccN3sY2Q03a5i1oCITLaN8IRrzdXe1RkcOokEkv356jUEKcMcMrTd TL30177GgMFFR7IPtsjk54319Nf7KBUFc+rLcLmGffINZI7W4080zuemFCvR7LcU FoZ19ETqQJxIk3Fbeu6n97rsP44tAGY65XQOF+aIaa92ERasJM4= =2A/M -----END PGP SIGNATURE-----

1 1