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
Hey,
I noticed that this suddenly stopped working:
ngompa@opensuse-tumbleweed-x86_64:~> rpm -E ".suse.tw%(.
/etc/os-release; echo $VERSION_ID)"
.suse.tw
Why doesn't the date part work anymore? It used to work a few months ago...
--
真実はいつも一つ!/ 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
Hi all,
during cleanup I noticed that building rubygems for SLES12 in breaks
with the following error:
[ 23s] + exec rpmbuild -ba --define '_srcdefattr (-,root,root)'
--nosignature --define '_build_create_debug 1'
/home/abuild/rpmbuild/SOURCES/rubygem-net-ssh-5_0.spec
[ 23s] error: Too many levels of recursion in macro expansion. It is
likely caused by recursive macro declaration.
[ 23s] error: Too many levels of recursion in macro expansion. It is
likely caused by recursive macro declaration.
[ 23s] error: Too many levels of recursion in macro expansion. It is
likely caused by recursive macro declaration.
[ 23s] error: Too many levels of recursion in macro expansion. It is
likely caused by recursive macro declaration.
[ 23s] error: Too many levels of recursion in macro expansion. It is
likely caused by recursive macro declaration.
This leads to an error later:
[ 24s] error: Failed build dependencies:
[ 24s] rubygem(ruby:2.2.0: is needed by
rubygem-net-ssh-5_0-5.0.2-0.x86_64
[ 24s] rubygem(ruby:2.3.0: is needed by
rubygem-net-ssh-5_0-5.0.2-0.x86_64
[ 24s] rubygem(ruby:2.4.0: is needed by
rubygem-net-ssh-5_0-5.0.2-0.x86_64
[ 24s] rubygem(ruby:2.5.0: is needed by
rubygem-net-ssh-5_0-5.0.2-0.x86_64
[ 24s] rubygem(ruby:2.6.0: is needed by
rubygem-net-ssh-5_0-5.0.2-0.x86_64
The macros have been defined in the prjconf long time ago and are still
matching what I find in Factory or dlre prjconf.
I'll try to setup a new project for testing this. Is there any place I
need to look besides prjconf and the macro package?
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
Hello,
I am planning on updating libfuse from version 2.9.9 to
3.4.2. Currently, we have both libfuse2 (source fuse-2.9.9 or just
fuse) and libfuse3 (source fuse-3.4.2 or fuse3). It would be nice
if all users would move from libfuse2 to libfuse3.
What would be the best method to accomplish this:
1. Simply update fuse to fuse-3.4.2
2. Mark fuse 3.4.2 as obsoletes fuse < 3, and ship both for a
while
3. Any other method
I am afraid we will break depending applications if we choose 1,
though it should be compatible.
--
Goldwyn
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi list,
I am currently trying to package a Rubygem that has no upstream release
yet (and that will probably stay like that for a while). Thus, I need to
build the gem myself.
I am facing now the following issues:
- The gem's version needs to be patched, so that it gets the git commit
as a suffix, thus making it apparent that it's a git snapshot.
- I need this gem to land in openSUSE:Factory, so it needs to adhere to
stricter rules.
My first try is currently in d:l:r:e:
https://build.opensuse.org/package/show/devel:languages:ruby:extensions/rub…
This has unfortunately the following problems preventing a submission to
Factory:
1. The patches in the repository are for adding them on top of the git
repository to build the gem, which is then fed into gem2rpm. Thus
they are not needed in the spec file, which makes the check script
decline this.
2. As there is no upstream gem yet on rubygems.org, the factory check
script cannot download the source from the URL that gem2rpm
generates.
I have tried to include just a snapshot of the upstream repository as
the source and build the gem during %build. Unfortunately this makes
%gem_install fail, because it expects to have a gem tracked in the
repository.
Does anyone have a suggestion how to proceed?
Thanks in advance,
Dan
--
Dan Čermák <dcermak(a)suse.com>
Software Engineer Development tools
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
Hi,
There is a package called "glm" in "devel:libraries:c_c++" project
(https://build.opensuse.org/package/show/devel:libraries:c_c++/glm),
that I'm maintainer of.
I just found out that this package is now developed at "science" project.
So now I see no reason for it to exist in d:l:c project. I'd like to
delete it, but there are some other packages linked to it. How should I
handle this? Should I request deletion of them? Or maybe is there some
magic that would allow to change them to link to "science" project?
--
Adam Mizerski
Thank you Stefan for clearing this up for me. Indeed, building against
HEAD is arguably an overkill.
So am I getting this correct that NVidia drivers' breakage is detected
proactively after all? If so, does nVidia driver breakage prevent a
Tumbleweed snapshot from being released?
Thank you in advance.
On Tue, Apr 16, 2019 at 6:05 PM Stefan Dirsch <sndirsch(a)suse.de> wrote:
>
> On Tue, Apr 16, 2019 at 05:14:34PM +0300, Andrei Dziahel wrote:
> > See, having them distributed separately is just fine (by me).
> >
> > What is not quite OK is that when kernel breaks NVIDIA kernel module,
> > there seems to be no way for anyone to know that, except via tracking
> > that rglinuxtech blog (/cc sndirtsch@suse: am I correct?). You guys
> > probably do have an in-house SUSE-only OBS installation, do you? If
> > so, it is feasible to set up continuous builds of
> > https://build.opensuse.org/project/show/X11:Drivers:Video against
> > https://build.opensuse.org/project/show/Kernel:HEAD in there, isn't
> > it?
>
> We do test build against Tumbleweed, which I believe should be sufficient.
> How many users are using bleeding edge Kernel:HEAD and are expecting NVIDIA
> drivers running afterwards?
>
> When installing the Tumbleweed NVIDIA driver RPMs after a kernel update a
> rebuild of the NVIDIA kernel modules is triggered, so unless changes in the
> kernel break the build of the driver, things are working also after a reboot
> of the new kernel. Luckily breaking the build doesn't happen so often. In this
> case I'm seing the failure in the TW test build, fix it ASAP and push the RPMs
> to NVIDIA immediately.
>
> Hope this helps.
>
> Stefan
>
> > On Wed, Mar 20, 2019 at 2:33 AM Simon Lees <sflees(a)suse.de> wrote:
> > >
> > >
> > >
> > > On 20/03/2019 03:04, Andrei Dziahel wrote:
> > > > Had anyone at SUSE tried to reach NVIDIA asking them for permission to
> > > > use desktop drivers in openQA so failing to build kernel module of
> > > > theirs would be soft fail at least?
> > > >
> > >
> > > The issue in some way is less a nvidia thing and more a kernel developer
> > > / licensing thing, in the past some kernel developers have felt that the
> > > nvidia driver violates the kernels licensing terms, as such openSUSE has
> > > respected the kernel developers with this opinion by not shipping /
> > > having nvidia drivers running within the openSUSE project. Atleast thats
> > > my recollection, I could remember wrong.
> > >
> > > > On Tue, Mar 19, 2019 at 1:25 PM Mathias Homann
> > > > <Mathias.Homann(a)opensuse.org> wrote:
> > > >>
> > > >> Am 2019-03-19 11:01, schrieb Stasiek Michalski:
> > > >>>> On the third hand, all the stuff I read on the opensuse lists about
> > > >>>> tumbleweed
> > > >>>> and its "quirks" is why I'm *not* using tumbleweed.
> > > >>>>
> > > >>>> - nvidia and tumbleweed kernels
> > > >>>
> > > >>> Maybe somebody will realize at some point that dkms is a better
> > > >>> option with a distro that changes kernels every week.
> > > >>
> > > >>
> > > >> AFAIK the nvidia drivers already use DKMS, and build "on the fly" when
> > > >> you install/upgrade the package. Problem is, Kernel 5.x did "something"
> > > >> that might break nvidia drivers...
> > > >>
> > > >> I've been told that it does not concern the desktop drivers, but what
> > > >> I've seen on the -factory list suggests otherwise.
> > > >>
> > > >> anyway, it's just so much more convenient for end users to get an
> > > >> automated package update to trigger the process than doing it manually -
> > > >> been there, done that for years until suse started having packages. This
> > > >> way all I have to do is click on the little rocket in ansible tower.
> > > >> Once. For X machines. ;)
> > > >>
> > > >> Cheers
> > > >> MH
> > > >
> > > >
> > > >
> > >
> > > --
> > >
> > > 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
> > >
> >
> >
> > --
> > Regards,
> > Andrei Dziahel
> >
>
> --
> Regards,
> Stefan Dirsch
>
> Public Key available
> ------------------------------------------------------
> Stefan Dirsch (Res. & Dev.) SUSE LINUX GmbH
> Tel: 0911-740 53 0 Maxfeldstraße 5
> FAX: 0911-740 53 479 D-90409 Nürnberg
> http://www.suse.de Germany
> ----------------------------------------------------------------
> SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
> HRB 21284 (AG Nürnberg)
> ----------------------------------------------------------------
--
Regards,
Andrei Dziahel
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
So it seems that right now someone is in the process of doing some
upgrade work in KDE:Qt. Whoever it is has turned publishing off, which
usually is a good idea...
...but in this case it leads to hundreds of packages in KDE:Framework,
KDE:Extras, and KDE:Applications being rebuilt, and being published, and
because publishing of KDE:Qt is turned off, being unable to be installed
due to missing dependencies. The really bad part is, that *some*
packages from those newly built ones *will* be installed, and some
others will be downgraded to what's in the base distribution, leaving
people with a general mish mash of librariy versions and potentially
seriously broken desktops.
So ... can someone **please** turn publishing in KDE:Qt back on?
And for next time: whoever disables publishing in KDE:Qt for upgrading
it, disable publishing (and building) in KDE:Frameworks5,
KDE:Applications, and KDE:Extra.
Thank you.
*le sigh*
Mathias
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Dear Geeko's fellows.
Last saturday's night April 6th, tigerfoot's main program had a serious segv that brought down my whole system.
To make it short, I've been extremely lucky about the fact that it happen at home, the swiss health care emergency team,
the rega ( https//rega.ch ) and all people during that night were all involved at a such great level.
Now a few day has passed, and even if the path will not be that short, I'm mainly out of danger.
Of course, some "details" have to change, and also rework about priorities in life.
First, I need to drastically minimize the in flow and as such I will unsubscribe most of the mailing list.
I also have to retire for an unknown time as maintainer of some packages, and of course my involvment in some repository will decrease to zero.
So if someone want to take the maintainer's role of one of my package, don't hesitate, try, ask for help to other mentors, send the SR
If it's not me directly, I trust my fellow repository maintainer to allow you to pick the role.
( You can find most of them here https://build.opensuse.org/user/show/bruno_friedmann )
I wish you all a perfect funny OSC19, a damn good Leap 15.1 release and all the best.
cu
--
Bruno Friedmann (tigerfoot)
Send from my mobile. Please excuse my brevity.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org