openSUSE Packaging January 2019

packaging@lists.opensuse.org

23 participants
12 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, 6 months

[opensuse-packaging] Elinks: package dropping

by Sébastien 'sogal' Poher

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

2 years

[opensuse-packaging] Build fails, because "nothing provides" my dependency

by Adam Mizerski

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 years, 1 month

[opensuse-packaging] Please check your packages in scope of 15.1

by Ludwig Nussel

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

2 years, 1 month

[opensuse-packaging] cmake finds packages and tells they are not found?

by Adam Mizerski

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

2 years, 1 month

[opensuse-packaging] Bogus rpmlint error packaging a shared C++ library

by John Paul Adrian Glaubitz

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

2 years, 1 month

[opensuse-packaging] Packaging Java applications using the Gradle build system

by Matthias Bach

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 years, 1 month

[opensuse-packaging] BuildRequires OR %dir

by Eric Schirra

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

2 years, 1 month

[opensuse-packaging] automatic locale() provides for translations?

by Ludwig Nussel

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 years, 1 month

[opensuse-packaging] Graphics maintainers

by Dave Plater

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 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging January 2019