openSUSE Packaging April 2019

packaging@lists.opensuse.org

19 participants
13 discussions

[opensuse-packaging] New macro to limit resources allocation per thread

by Tomas Chvatal

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

1 year, 8 months

[opensuse-packaging] Why doesn't this macro work properly anymore?

by Neal Gompa

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

2 years

[opensuse-packaging] Building rubygems for SLES12 broken due to "Too many levels of recursion in macro expansion"

by Johannes Kastl

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

2 years

[opensuse-packaging] Updating libfuse rpm

by Goldwyn Rodrigues

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

2 years

[opensuse-packaging] Packaging a Rubygem that has no upstream release

by dcermak＠suse.com

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)

2 years

[opensuse-packaging] glm cleanup

by Adam Mizerski

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

2 years

Re: [opensuse-packaging] Packagers breaking repositories ...

by Andrei Dziahel

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

2 years

[opensuse-packaging] Packagers breaking repositories ...

by Mathias Homann

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

2 years

[opensuse-packaging] tigerfoots' SEGV and some pets to adopt

by Bruno Friedmann

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

2 years, 1 month

[opensuse-packaging] "Interesting" perl package testing failure

by Hans-Peter Jansen

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

2 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging April 2019