openSUSE Packaging November 2018

packaging@lists.opensuse.org

26 participants
19 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

2 years, 8 months

[opensuse-packaging] Generalized %license <-> %doc macros backward compability patch

by Mikhail Kasimov

Hello, list! After having couple of tests on [0] https://build.opensuse.org, let me introduce a way (workable patch) how to have normal %license <-> %doc RPM-macros backward compability for wide row of various versions of different RPM-based distros (RedHat/CentOS/Fedora/SUSE/openSUSE/Mageia/Mandriva). Patch is based on: [1] https://lists.opensuse.org/opensuse-factory/2016-02/msg00167.html [2] https://lists.opensuse.org/opensuse-packaging/2018-11/msg00015.html Patch code: ========== # # Copy LICENSE(-s) stuff to %%doc for: # # - RedHat Enterprise Linux 6 and lower # - CentOS 6 and lower # - Fedora 18 and lower # # - Scientific Linux 6 and lower # # - SUSE Linux Enterprise 12 SP2 and lower # - openSUSE Leap 42.2 and lower # # - Mageia 4 and lower and all Mandriva line # # Copy LICENSE(-s) stuff to %%license for: # # - RedHat Enterprise Linux 7 and higher # - CentOS 7 and higher # - Fedora 19 and higher # # - Scientific Linux 7 and higher # # - SUSE Linux Enterprise 12 SP3 and higher # - openSUSE Leap 42.3 and higher # - openSUSE Tumbleweed and its derivatives # # - Mageia 5 and higher # # %if ( 0%{?sle_version} > 120200 && !0%{?is_opensuse} ) || ( 0%{?sle_version} > 120200 && 0%{?is_opensuse} ) || 0%{?suse_version} > 1500 || 0%{?rhel_version} > 600 || 0%{?centos_version} > 600 || 0%{?scientificlinux_version} > 600 || 0%{?fedora_version} > 18 || 0%{?mageia} > 4 %doc <put all your package readme and other information stuff here, except license(-s) stuff> %license <put your package license(-s) stuff here only> %else %doc <put all your package readme, license(-s) and other information stuff here> %endif ========== Gived in patch versions of dstros are settled after having couple of tests on [0] for different packages to get green "succeeded" biulding output for all. Actually, for example: [3] https://build.opensuse.org/package/show/home:k_mikhail/GOST34.11-2012 [4] https://build.opensuse.org/package/show/home:k_mikhail:branches:home:oniels… Hope, this patch will be useful/helpful for packagers, who want to build their packages for wide row of different RPM-based distros and their various versions and to be OK with building guidelines ([5], [6]). Feel free to update this patch, if needed. Thanks! References: ========== Fedora: [5] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/L… openSUSE: [6] https://en.opensuse.org/openSUSE:Specfile_guidelines#License_files Distribution detection codes: [7] https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 5 months

[opensuse-packaging] Following upstream git repo with gnulib: "./bootstrap && ./configure && make" without network?

by Bernhard Voelker

Hi *, I'm trying to follow an upstream GNU package's Git repo which has a gnulib submodule, and PO files from 'translationproject.org'. Example: https://build.opensuse.org/package/show/home:berny:branches:fromgit/hello Do I do it right? Long story: In this case, I need to create a distribution tarball without gnulib and PO from network. Furthermore, "obs_scm" service doesn't create a full Git clone; so in my example - GNU hello, for simplicity - I needed to add a hack to be able to create the manpage. The idea is: a) let _service get the package from the remote Git repo. (unfortunately, this yields the working tree without the '.git/' history). b) let _service download the PO files --> "SourceXY". c) GNU hello specific: manpage creating is usually only done in maintainer environment, i.e., with a '.git/' directory. Add a little patch to work around it. d) in '%prep'', copy the PO files into the build tree. e) in '%build', create the LINGUAS file. f) in %build: f.1) create the intermediate distribution tarball using: ./bootstrap ... && ./configure && make all dist f.2) create the final build from the above distribution tarball: tar -xf ... && ./configure && make Does anybody else do something like that? Thanks & have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 5 months

[opensuse-packaging] Problems with packaging systemd.timer

by Eric Schirra

Hello, me have reached an Bugentry, that i shoud insert/change cron into systemd.timer in my package. First i must say i'm not a friend of this. Imho systemd catch to many services and i don't like journalctl. And the systemd.timer are many more work than cron with no benfit. Anyway, i have now add systemd.timer to my package to learn about systemd.timer. But now rpmlint rise some warnings, where i think it is not okay. 1.) I must create two files. A service- and a timer-file But rpmlint says now i must also create %service_add_pre <package>.service and so on. But why? This service file is not a 'normal' service file. It is only used for timer. 2.) Rpmlint rise up warning: suse-missing-rclink <package> But why? See above. It is only a file for systemd.timer. 3.) <package>.noarch: W: non-etc-or-var-file-marked-as-conffile /usr/lib/systemd/system/<package>.service <package>.noarch: W: non-etc-or-var-file-marked-as-conffile /usr/lib/systemd/system<package>.timer A file not in /etc or /var is marked as being a configuration file. Please put your conf files in /etc or /var. But i must tag in spec with config(noreplace), because a user perhaps want to change the time or logfile or something else. What should i do to prevent time or command changes at update? 4.) With systemd.timer no mail will be send if service failed. What think opensuse to do to implement this feature? Arch have something do: https://wiki.archlinux.org/index.php/Systemd/Timers 5.) When i want run a timer every day and i insert a * for day field, systemd rise up an error. So i must the 'day field' empty. Is this an bug from systemd? Or is this volitional? On time field i must insert *. Where is there the logic? -- 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 years, 5 months

[opensuse-packaging] Best strategy for dealing with Python version numbers

by John Paul Adrian Glaubitz

Hi! RPM/DPKG uses a different version ordering than Python. In particular, Python has a different logic for pre-releases. While DPKG/RPM uses the tilde for lowering version numbers meaning that RC versions have to be constructed as something like "1.0.0~rc2", Python uses "1.0.0rc2". This means, that for Python, "1.0.0rc2" is a lower version than "1.0.0" while for DPKG/RPM, "1.0.0rc2" is actually higher than "1.0.0". Since lots of Python packages with the rc-suffix exist, I assume there is a consensus in openSUSE on how to map Python RC versions to RPM RC versions, isn't there? What's the suggested strategy? Are there any example packages? Adrian > [1] https://www.python.org/dev/peps/pep-0440/#pre-releases -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 5 months

[opensuse-packaging] State of libreoffice-branding-openSUSE

by Sébastien 'sogal' Poher

Hi all, During a FOSS event, this week-end I had contact with a member of the LibreOffice project. He asked me if, in openSUSE, we include a special branding for the Libreoffice suite. I checked and it appears that the package libreoffice-branding-openSUSE is not available anymore in Leap (not maintained ?). Does anyone of you know the reason for it or has any news of the state of this package ? Cheers, -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher

3 years, 5 months

[opensuse-packaging] Python package fails to build with LC_ALL=C

by John Paul Adrian Glaubitz

Hi! I am currently packaging python-aioresponses [1] which fails to build from source in OBS with the following backtrace: [ 37s] + echo python3 [ 37s] + /usr/bin/python3 setup.py build '--executable=/usr/bin/python3 -s' [ 37s] Traceback (most recent call last): [ 37s] File "setup.py", line 6, in <module> [ 37s] pbr=True, [ 37s] File "/usr/lib/python3.6/site-packages/setuptools/__init__.py", line 139, in setup [ 37s] _install_setup_requires(attrs) [ 37s] File "/usr/lib/python3.6/site-packages/setuptools/__init__.py", line 132, in _install_setup_requires [ 37s] dist.parse_config_files(ignore_option_errors=True) [ 37s] File "/usr/lib/python3.6/site-packages/setuptools/dist.py", line 492, in parse_config_files [ 37s] _Distribution.parse_config_files(self, filenames=filenames) [ 37s] File "/usr/lib64/python3.6/distutils/dist.py", line 395, in parse_config_files [ 37s] parser.read(filename) [ 37s] File "/usr/lib64/python3.6/configparser.py", line 697, in read [ 37s] self._read(fp, filename) [ 37s] File "/usr/lib64/python3.6/configparser.py", line 1015, in _read [ 37s] for lineno, line in enumerate(fp, start=1): [ 37s] File "/usr/lib64/python3.6/encodings/ascii.py", line 26, in decode [ 37s] return codecs.ascii_decode(input, self.errors)[0] [ 37s] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 44: ordinal not in range(128) [ 37s] error: Bad exit status from /var/tmp/rpm-tmp.UucssU (%build) Turns out, this is an issue with the locale: glaubitz@suse-laptop:~/suse/home:glaubitz:branches:devel:languages:python/python-aioresponses/aioresponses-0.5.0> LC_ALL=C python3 setup.py build '--executable=/usr/bin/python3 -s' Traceback (most recent call last): File "setup.py", line 7, in <module> pbr=True, File "/usr/lib/python3.6/site-packages/setuptools/__init__.py", line 139, in setup _install_setup_requires(attrs) File "/usr/lib/python3.6/site-packages/setuptools/__init__.py", line 132, in _install_setup_requires dist.parse_config_files(ignore_option_errors=True) File "/usr/lib/python3.6/site-packages/setuptools/dist.py", line 492, in parse_config_files _Distribution.parse_config_files(self, filenames=filenames) File "/usr/lib64/python3.6/distutils/dist.py", line 395, in parse_config_files parser.read(filename) File "/usr/lib64/python3.6/configparser.py", line 697, in read self._read(fp, filename) File "/usr/lib64/python3.6/configparser.py", line 1015, in _read for lineno, line in enumerate(fp, start=1): File "/usr/lib64/python3.6/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 44: ordinal not in range(128) glaubitz@suse-laptop:~/suse/home:glaubitz:branches:devel:languages:python/python-aioresponses/aioresponses-0.5.0> python3 setup.py build '--executable=/usr/bin/python3 -s' running build running build_py running egg_info writing aioresponses.egg-info/PKG-INFO writing dependency_links to aioresponses.egg-info/dependency_links.txt writing requirements to aioresponses.egg-info/requires.txt writing top-level names to aioresponses.egg-info/top_level.txt [pbr] Reusing existing SOURCES.txt glaubitz@suse-laptop:~/suse/home:glaubitz:branches:devel:languages:python/python-aioresponses/aioresponses-0.5.0> I'm not sure though why the locale should have any impact on setuptools. Anyone got an idea? I've been debugging this for an hour now :-). Adrian > [1] https://build.opensuse.org/package/show/home:glaubitz:branches:devel:langua… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 5 months

[opensuse-packaging] Trouble building the python2 version in a single-spec package

by John Paul Adrian Glaubitz

Hi! I am currently trying to update python-dns-lexicon to the latest upstream version. This newer version pulls in three new dependencies which I have already packaged: - python-PyNameCheap - python-localzone - python-zeep I have already successfully packaged PyNameCheap and localzone, however I have trouble with zeep which pulls in aiohttp and aioresponse. aiohttp is a package which is currently set to build python3 packages only which would mean that python-dns-lexicon would be transitively python3-only which I wanted to avoid. aiohttp is currently broken anyway, so I am working on fixing that, too. The first thing I tried was to enable the python2 build of the package with the following change: -%{?!python_module:%define python_module() python3-%{**}} -%define skip_python2 1 +%{?!python_module:%define python_module() python-%{**} python3-%{**}} However, when trying to build python-aiohttp, I am still getting: unresolvable: nothing provides python2-devel >= 3.5.3 nothing provides python2-async_generator nothing provides python2-async_timeout >= 3.0 nothing provides python2-idna_ssl >= 1.0.0 nothing provides python2-multidict >= 4.0 nothing provides python2-yarl >= 1.0 I have already checked the project configuration for obvious problems and re-read the spec file multiple times, but I can't figure out what I am missing. Anyone got any idea? Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 6 months

Re: [opensuse-packaging] Who to ask for aqsis OBS packaging ?

by Hans-Peter Jansen

Just replying to a ML member for no good reasons is considered harmful by many parties(!). On Dienstag, 13. November 2018 13:31:43 J. Scheurich wrote: > >> It's there, but suffers from bit rot: > >> > >> https://build.opensuse.org/package/show/graphics:rendering/aqsis > > It looks like, this is aqsis-1.8.2.tar.bz2 which is the current tar-ball > at sourceforge. > There are some changes in the current git (from 2014-09-10), > should i try to port the current git ? Here's an example, how to fetch a git project: https://build.opensuse.org/package/view_file/home:frispete:telephony:asteri… Just run: osc service dr to build the tarball. Good luck, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 6 months

[opensuse-packaging] Who to ask for aqsis OBS packaging ?

by J. Scheurich

Hi, Who to ask for aqsis OBS packaging ? Aqsis is a movie renderer using the Renderman Image Bytestream (RIB) format. I am the maintainer of white_dune https://software.opensuse.org/package/white_dune http://wdune.ourproject.org/ a simple VRML/X3D modeller and animation tool. The newest version 0.99pl1144 support (limited) conversion to the RIB format. To create images from a RIB file under Linux aqsis (http://www.aqsis.org/) (or renderman) is needed. It looks like aqis has not been ported to OpenSuse (unlike Ubuntu and Debian). I can try to port aqsis using the OBS, but who to ask for teamwork ? I am unable to find the email adress of the graphics OBS admin 8-( so long MUFTI -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 6 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging November 2018