January 2019 - 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] Elinks: package dropping
by Sébastien 'sogal' Poher 08 Feb '19

08 Feb '19

Hi all, I am maintainer of Elinks web browser. I consider dropping it from Factory and in a second time from network/elinks because : * it has not received real updates from upstream for more than one year and a half [0] * I could not get in touch with any of the upstream developers * the project web page states that the last release is a pre release done in 2012 [1] * its bug tracking system is down [2] as well the mailing list [3] If anyone has really good reasons why I should not drop it or is interested in taking over maintainership, let me know, otherwise I will wait until the weekend and make a drop request. Regards, [0] https://repo.or.cz/elinks.git/shortlog [1] http://elinks.cz/ [2] http://bugzilla.elinks.cz/ [3] http://linuxfromscratch.org/mailman/listinfo/elinks-dev/ -- Sébastien Poher -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 3

[opensuse-packaging] Build fails, because "nothing provides" my dependency
by Adam Mizerski 31 Jan '19

31 Jan '19

Hi, I'm trying to package the newest ethereum-cpp version. It requires libjsonrpc-cpp version 0.7.0. The package that is already available provides version 1.1.1. Thankfully, libjsonrpc-cpp0 follows good practice of building shared libraries with proper versioning. I created a new package libjsonrpc-cpp0, that provides the older version. Now both packages create libjsonrpc-cpp-devel package, but with different versions. (AFAIK this is the proper way of packaging multiple library versions, if header files sits in the same place) You can find all my packages at https://build.opensuse.org/project/show/home:etamPL:branches:network:crypto… The problem I have now, is that ethereum-cpp does not build, because it says "nothing provides pkgconfig(libjsonrpccpp-client) = 0.7.0". But if I look into libjsonrpc-cpp-devel-0.7.0-1.1.x86_64.rpm file, into what it provides, there is exactly "pkgconfig(libjsonrpccpp-client) = 0.7.0". Am I doing something wrong? -- Adam Mizerski

2 2

[opensuse-packaging] Please check your packages in scope of 15.1
by Ludwig Nussel 30 Jan '19

30 Jan '19

Hi, Leap 15.1 will enter it's beta phase soon. Time to review whether 15.1 has the right versions of your packages! You can do that by either installing the current Alpha versions¹ or by checking OBS². Also, please have a look at your personal page in OBS and check for open reviews³. (Semi)automated submissions from Factory need maintainer review as usual. So in case you missed the notifications from OBS please have a look if there are submissions that need your approval. cu Ludwig [1] https://software.opensuse.org/ [2] https://build.opensuse.org/project/show/openSUSE:Leap:15.1 [3] https://build.opensuse.org/user/tasks -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 5

[opensuse-packaging] cmake finds packages and tells they are not found?
by Adam Mizerski 30 Jan '19

30 Jan '19

Hi, I need help from a cmake expert. I'm trying to update ethereum-cpp package to the latest version. It uses Hunter (https://hunter.sh/) to download and compile dependencies. Of course, to make it compile on build service I had to disable Hunter (easy, just add -DHUNTER_ENABLED=OFF to cmake) and adjust all find_package calls, to use system provided libraries. And now I hit the wall. Some of required libraries (ethash, Snappy and yaml-cpp) are built with cmake themselves and are providing cmake files in /usr/lib64/cmake. As far as I understood cmake manual, they should be used with "find_package(<name> CONFIG REQUIRED)". Cmake does not complain about any missing libraries and in log linked below it shows that it uses those provided files. But files generated in build directory contain "<name>-NOTFOUND" values and build fails. Here you can find my current work: https://build.opensuse.org/package/show/home:etamPL:branches:network:crypto… Here you can find log from running cmake with "--trace --debug-output": http://susepaste.org/77797237 -- Adam Mizerski

1 1

[opensuse-packaging] Bogus rpmlint error packaging a shared C++ library
by John Paul Adrian Glaubitz 28 Jan '19

28 Jan '19

Hi! Amazon has recently created new C++ dependencies for their AWS SDK in C++, those are aws-c-common, aws-c-event-stream and aws-checksums. I am currently in the process of packaging aws-c-common as a shared library package [1]. Unfortunately, I got stuck in the process with one strange issue: [ 18s] libaws-c-common1.0.0.x86_64: W: shlib-unversioned-lib libaws-c-common.so.0unstable [ 18s] Your package matches the Shared Library Policy Naming Scheme but contains an [ 18s] unversioned library. Therefore it is very unlikely that your package can be [ 18s] installed in parallel to another version of this library package. Consider [ 18s] moving unversioned parts into a runtime package. [ 18s] [ 18s] libaws-c-common1.0.0.x86_64: E: shlib-policy-name-error (Badness: 10000) libaws-c-common0unstable [ 18s] Your package contains a single shared library but is not named after its [ 18s] SONAME. The thing is that the actual packages don't contain the symbolic link in question: suse-laptop:/var/tmp/build-root/openSUSE_Factory-x86_64/home/abuild/rpmbuild/RPMS/x86_64 # rpm -ql *rpm |grep unstable suse-laptop:/var/tmp/build-root/openSUSE_Factory-x86_64/home/abuild/rpmbuild/RPMS/x86_64 # Yet rpmlint is complaining. Anyone has got any idea? Adrian > [1] https://build.opensuse.org/package/show/home:glaubitz:branches:devel:librar… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 10

[opensuse-packaging] Packaging Java applications using the Gradle build system
by Matthias Bach 14 Jan '19

14 Jan '19

Hi, I recently looked into updating the freemind package, as it is both, severly outdated and doesn't build on versions newer Leap 42. However, I ran into somewhat of a road block as upstream switch from a classic Ant build to using Gradle [1]. Is there any other package in openSUSE using Gradle? I searched the Wiki for documentation on how to package software that uses Gradle but sadly failed to find anything. In case of Freemind there is the additional problem that the package assumes Gradle to be present in the system. However, openSUSE doesn't package it. I think this is on purpose, as some helpers are packaged and the recommended way to use Gradle anyhow is to have the Gradle Wrapper [2] in the source code. Yet, I fear that, even if I shipped the Gradle Wrapper as an additional source, this would not work as the Gradle Wrapper will attempt to pull Gradle from the internet. Do you have any recommendation as to how to proceed? I would hate to have to tarball-install this to my wife's machine. Kind Regards, Matthias [1]: https://gradle.org/ [2]: https://docs.gradle.org/5.1.1/userguide/gradle_wrapper.html -- 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] BuildRequires OR %dir
by Eric Schirra 13 Jan '19

13 Jan '19

Hello, i have a question to packaging. Problem is. I have a dir or file which is under a directory from other package. I can now BuildRequires: OtherPackage OR i can include %dir in spec. Example: New file foo is under /srv/www/htdocs/newfile. /srv/www/htdocs belongs to package apache2. And newfile belongs to new package. In spec i can now insert BuildRequires: apache2 OR I insert %dir /srv/www/htdocs (It's only an example) I prefered BuildRequires because the dir /srv/www/htdocs belongs to apache, not to newpackage. But what is the preferred solution? What is the right way for openSUSE packaging style guides. I hope someone from openSUSE itself can help me. Sorry. I want not the opinion or surmise from 'normal' packager. I want a answer from top. A answer if it exists a standard from SUSE self. I hope you understand what i want. :-) Regards Eric -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 9

[opensuse-packaging] automatic locale() provides for translations?
by Ludwig Nussel 08 Jan '19

08 Jan '19

Hi, Many packages split off translations into a -lang subpackage. It's optional so the common way to package this is that the main package recommends the -lang package: $ rpm -q --recommends bash bash-doc = 4.4 bash-lang = 4.4 By default however that means the -lang packages are installed always, no matter whether the -lang package actually provides translations for the system's language. At the same time the dependency solver recognizes special locale() provides so it knows when packages are locale specific: $ rpm -q --provides ipa-pmincho-fonts|grep locale locale(ja) So in case no other package pulls in ipa-pmincho-fonts, it would still get installed if the system is installed in Japanese. There's also a variant that associates the locale specific package with another package: $ rpm -q --provides libreoffice-l10n-de|grep locale locale(libreoffice:de) Ie that one gets installed on a German system if libreoffice gets installed too. Furthermore we use %find_lang to tag all translation files with their locale already: $ rpm -q --qf '[%{filelangs} %{filenames}\n]' bash-lang|head -3 bg /usr/share/locale/bg/LC_MESSAGES/bash.mo ca /usr/share/locale/ca/LC_MESSAGES/bash.mo cs /usr/share/locale/cs/LC_MESSAGES/bash.mo [...] However: $ rpm -q --provides bash-lang bash-lang = 4.4-lp150.8.3.1 bash-lang-all = 4.4 Surprise: $ rpm -q --provides MozillaFirefox-translations-common|grep locale locale(MozillaFirefox:ar;ca;cs;da;de;en_GB;el;es_AR;es_CL;es_ES;fi;fr;hu;it;ja;ko;nb_NO;nl;pl;pt_BR;pt_PT;ru;sv_SE;zh_CN;zh_TW) Firefox does that manually though. Wouldn't it make sense to automatically tag all -lang packages with locale() and get rid of the recommends? Since English normally doesn't have mo files, a consequence would be that a system installed in English wouldn't pull in any -lang packages. Ie would be smaller without requiring --no-recommends. Any takers? :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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] Graphics maintainers
by Dave Plater 08 Jan '19

08 Jan '19

Hi, I created a new package for the use of blender in response to a bug report. Sorry for the impatience but I would appreciate it if someone could accept sr#663570 and make me a maintainer of the package so that I can send it and the OSL enabled blender to Factory. Thanks Dave P -- 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] Non-building packages in Science and Education to be removed
by Todd Rme 04 Jan '19

04 Jan '19

Currently there are a large number of unmaintained packages that fail to build in the Science and Education repositories. They haven't been updated in years and fail to build on at least Tumbleweed, and in many cases other releases as well. There was recently a request to remove these. I will deny the requests in order to give people a chance to fix the packages. Anyone interested in any of these packages please fix them in the next 4 weeks. Any packages that are still not working on Monday, January 7 will be removed. Here is a list of failing packages: Education / HeeksART Education / HeeksCAD Education / HeeksCNC Education / MultiplicationStation Education / TuxMathScrabble Education / VUE Education / chemtool Education / fet Education / fpc-cross-i386-linux Education / freeon Education / fzclips Education / galib Education / gnome-chemistry-utils Education / graphthing Education / gtkextra2 Education / italc Education / itext Education / jMemorize Education / k3dsurf Education / kdeedu3 Education / kiwi-config-openSUSE-Edu Education / klogic Education / klogoturtle Education / koctave Education / krecipes Education / kseg Education / ksociograma Education / lenmus Education / lomse Education / moodle3_2 Education / mpqc Education / nanoxml Education / noteedit Education / open-axiom Education / opensuse-education-release Education / php5-pear-xml_parser Education / piklab Education / planets Education / plutimikation Education / release-notes-edu Education / score-reading-trainer Education / skelcd-education-desktop Education / sonic-pi Education / squidguard-blacklists Education / tablix Education / tagainijisho Education / xaralx Education / xlogo science / ASL science / CGM science / OpenVSP science / UGENE science / alberta science / arrayfire science / babel science / boxshade science / clipper science / code_saturne science / coot science / dolfin science / emboss-explorer science / engrid science / forge science / gbench science / glemon science / gnome-chemistry-utils science / ised science / keepnote science / libadjoint science / libmesh science / moab science / molekel science / mshr science / openms science / openvibe science / prank science / pyqpcr science / silo science / slepc science / superlu_dist science / tao science / taucs science / treeviewx science / vrpn science / xdrawchem science / zoltan -- 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] Re: Non-building packages in Science and Education to be removed
by Lars Vogdt 04 Jan '19

04 Jan '19

Am January 2, 2019 8:48:04 PM UTC schrieb Egbert Eich <eich(a)suse.com>: > > Is this kind of an ego trip that you need to do now, when everybody > > else wants to enjoy his vacation? > >Lars, this doesn't look like an ego trip - it is more an attempt to >sanitize things. Looking at the 'sience' project which it huge >cleaning up packages which have not received any attention for years >may not be the worst thing to do. Well, if someone would take over and fix these packages, I would totally agree with you. And I accepted a lot of submit requests or even maintainer requests already. The people behind these requests have my full respect and I'm very, very thankful for the work and time they spent. But deleting others work because you want to "clean up" (what? for which reason?) is not the way to go in my eyes - and your arguments do not change my feeling. >Of course it would be a better solution to move these packages to a >separate (sub-)repository until someone gets around to fix and move >them back. As long as they are "build disabled", moving them "out of sight" makes no change (and no sense) at all. But in OBS, you could of course request a new project called: "my 100% working packages" and start your work there. But, stop, isn't this project called Factory already? ;-) >Unfortunately, IHMO osc still doesn't offer this. IMHO for a very good reason. So I like to request that we just invest the time we waste here for the discussion into fixing the packages and everyone would be happy. >BTW: regarding: 'everybody else wants to enjoy his vacation' - sure, >this is you and me: we do this for work. Some openSUSE contributors >do this in their spare time and - surprise - have more spare time >available during their vacation. I would be more than happy if I get paid for the work you mention. Instead it's my work at SUSE that blocks me from fixing the packages in discussion. Happy New Year, Lars -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2