April 2019

[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)... … [View More]

7 12

[opensuse-packaging] Why doesn't this macro work properly anymore?
by Neal Gompa 28 Apr '19

28 Apr '19

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

3 4

[opensuse-packaging] Building rubygems for SLES12 broken due to "Too many levels of recursion in macro expansion"
by Johannes Kastl 21 Apr '19

21 Apr '19

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 … [View More]

3 3

[opensuse-packaging] Updating libfuse rpm
by Goldwyn Rodrigues 19 Apr '19

19 Apr '19

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 … [View More]

2 2

[opensuse-packaging] Packaging a Rubygem that has no upstream release
by dcermak＠suse.com 17 Apr '19

17 Apr '19

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.… [View More]

1 0

[opensuse-packaging] glm cleanup
by Adam Mizerski 17 Apr '19

17 Apr '19

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 … [View More]

2 1

Re: [opensuse-packaging] Packagers breaking repositories ...
by Andrei Dziahel 16 Apr '19

16 Apr '19

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 … [View More]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 [View Less]

1 0

[opensuse-packaging] Packagers breaking repositories ...
by Mathias Homann 16 Apr '19

16 Apr '19

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 … [View More]

12 23

[opensuse-packaging] tigerfoots' SEGV and some pets to adopt
by Bruno Friedmann 12 Apr '19

12 Apr '19

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, … [View More]

2 1

[opensuse-packaging] "Interesting" perl package testing failure
by Hans-Peter Jansen 09 Apr '19

09 Apr '19

Hi, in an attempt to upgrade PgBadger, I stumbled across a strange testing failure, built here: https://build.opensuse.org/package/show/home:frispete:Tumbleweed/PgBadger [ 74s] Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.5869h3 [ 74s] + umask 022 [ 74s] + cd /home/abuild/rpmbuild/BUILD [ 74s] + cd pgbadger-10.3 [ 74s] + make test TEST_VERBOSE=1 [ 74s] PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "- MTest::Harness" "-e" "undef *Test::Harness::Switches; … [View More]test_harness(1, 'blib/ lib', 'blib/arch')" t/*.t [ 75s] t/01_lint.t ......... [ 75s] 1..2 [ 75s] ok 1 - PERL syntax check [ 75s] ok 2 - pod syntax check [ 75s] ok [ 127s] # Failed test 'syslog report to stdout' [ 127s] # at t/02_basics.t line 45. [ 127s] # Looks like you failed 1 test of 10. [ 127s] t/02_basics.t ....... [ 127s] 1..10 [ 127s] ok 1 - Inline help [ 127s] ok 2 - Light log report to stdout [ 127s] ok 3 - Light log report to HTML [ 127s] ok 4 - Light log to binary [ 127s] ok 5 - From binary to JSON [ 127s] ok 6 - Incremental mode report [ 127s] ok 7 - Ressources files in incremental mode [ 127s] ok 8 - Light log from STDIN [ 127s] ok 9 - Multiple output format [ 127s] not ok 10 - syslog report to stdout [ 127s] Dubious, test returned 1 (wstat 256, 0x100) [ 127s] Failed 1/10 subtests [ 127s] # Failed test 'syslog report to stdout' [ 127s] # at t/02_basics.t line 45. [ 127s] # Looks like you failed 1 test of 10. [ 127s] t/02_basics.t ....... [ 127s] 1..10 [ 127s] ok 1 - Inline help [ 127s] ok 2 - Light log report to stdout [ 127s] ok 3 - Light log report to HTML [ 127s] ok 4 - Light log to binary [ 127s] ok 5 - From binary to JSON [ 127s] ok 6 - Incremental mode report [ 127s] ok 7 - Ressources files in incremental mode [ 127s] ok 8 - Light log from STDIN [ 127s] ok 9 - Multiple output format [ 127s] not ok 10 - syslog report to stdout [ 127s] Dubious, test returned 1 (wstat 256, 0x100) [ 127s] Failed 1/10 subtests [ 144s] t/03_consistency.t .. [ 144s] 1..6 [ 144s] ok 1 - Generate intermediate binary file from log [ 144s] ok 2 - Generate json report from binary file [ 144s] ok 3 - Consistent count [ 144s] ok 4 - Consistent query_total [ 144s] ok 5 - Consistent peak write [ 144s] ok 6 - pgBouncer connections [ 144s] ok [ 144s] [ 144s] Test Summary Report [ 144s] ------------------- [ 144s] t/02_basics.t (Wstat: 256 Tests: 10 Failed: 1) [ 144s] Failed test: 10 [ 144s] Non-zero exit status: 1 [ 144s] Files=3, Tests=18, 70 wallclock secs ( 0.06 usr 0.03 sys + 51.16 cusr 3.90 csys = 55.15 CPU) [ 144s] Result: FAIL [ 144s] Failed 1/3 test programs. 1/18 subtests failed. No idea, why it is running t/02_basics.t twice. Interestingly, a local build shows significantly different issues: [ 2s] Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.hj5puV [ 2s] + umask 022 [ 2s] + cd /home/abuild/rpmbuild/BUILD [ 2s] + cd pgbadger-10.3 [ 2s] + make test TEST_VERBOSE=1 [ 2s] PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "- MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/ lib', 'blib/arch')" t/*.t [ 2s] t/01_lint.t ......... [ 2s] 1..2 [ 2s] ok 1 - PERL syntax check [ 2s] ok 2 - pod syntax check [ 2s] ok [ 3s] [ 3s] bunzip2: I/O or other error, bailing out. Possible reason follows. [ 3s] bunzip2: Broken pipe [ 3s] Input file = t/fixtures/light.postgres.log.bz2, output file = (stdout) [ 5s] [ 5s] bunzip2: I/O or other error, bailing out. Possible reason follows. [ 5s] bunzip2: Broken pipe [ 5s] Input file = t/fixtures/light.postgres.log.bz2, output file = (stdout) [ 8s] [...] Running the tests manually in the extracted package succeed. Hrmpf. Obviously, the problems are related to piping in sub-shells of the test scripts, but even Devel::Trace and stracing them didn't reveal anything obvious.. Being a complete Perl noob, I'm running out of ideas, what's wrong here. The package works well, btw. May some enlightened Perl soul could have a brief look, please? Thanks in advance, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org [View Less]

1 0

Main

Development

Information

Community

Social Media

Other

openSUSE Packaging