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
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 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
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
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
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
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
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
-----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-----