December 2018 - 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] 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] rpmlint(?): W: no-version-in-last-changelog
by Stefan Seyfried 28 Dec '18

28 Dec '18

Hi, can we please remove this obviously broken check? [ 6s] RPMLINT report: [ 6s] =============== [ 6s] vdr-plugin-satip.x86_64: I: binary-or-shlib-calls-gethostbyname /usr/lib64/vdr/libvdr-satip.so.2.4.0 [ 6s] The binary calls gethostbyname(). Please port the code to use getaddrinfo(). [ 6s] [ 6s] vdr-plugin-satip.src: W: no-version-in-last-changelog [ 6s] vdr-plugin-satip.x86_64: W: no-version-in-last-changelog [ 6s] The latest changelog entry doesn't contain a version. Please insert the [ 6s] version that is coherent with the version of the package and rebuild it. [ 6s] [ 6s] 2 packages and 0 specfiles checked; 0 errors, 2 warnings. [ 6s] [ 6s] [ 6s] strolchi finished "build vdr-plugin-satip.spec" at Wed Dec 26 17:14:57 UTC 2018. seife@strolchi:~/buildservice/vdr:unstable/vdr-plugin-satip> head -5 *es ------------------------------------------------------------------- Wed Dec 26 16:56:03 UTC 2018 - Stefan Seyfried <seife+obs(a)b1-systems.com> - update to version 2.4.0 (2018-04-15): - Updated for vdr-2.4.0 BTW the warning is absolutely useless, because I can make lots of changes to a package that don't affect the version at all. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 13

[opensuse-packaging] Querying version of a package
by Axel Braun 26 Dec '18

26 Dec '18

Good evening, tl;dr I have a package foo, depending on package bar. If I query the version of bar on the command line I get: rpm -q --qf '%{VERSION}' bar -> 4.6.9 (correct result) If I do the same in the build environment (specfile) I get the version of foo instead (wrong result) Any idea where this comes from, and how to fix? Long version: https://forums.opensuse.org/showthread.php/534165-Checking-version-of-a-req… Have a good evening Axel -- 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] Packaging a (mostly) header only C++ library
by dcermak＠suse.com 20 Dec '18

20 Dec '18

Hi list, I would like to package a (kind-of) header only C++ library (https://github.com/emilk/loguru). The problem is, that it actually ships a cpp file in it's source tree (so I guess it needs to be compiled to a shared library?). The issue at hand is, that loguru is designed to be embedded in your C++ project (there is *a lot* of compile time switches) and even running the test suite from a shared library requires a lot of patching of the source tree. What would be the correct procedure for packaging? Create a shared library nevertheless? Or create multiple libraries with some common compile time switches? Or just install the sources into the file system? Thanks in advance, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://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 7

[opensuse-packaging] Generalized %license <-> %doc macros backward compability patch
by Mikhail Kasimov 11 Dec '18

11 Dec '18

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

4 6

[opensuse-packaging] rpmlint rules for /var/run
by Todd Rme 11 Dec '18

11 Dec '18

I am trying to get xrootd updated to work with systemd (as well as various other improvements), but I am running into two rules in rpmlint and I can't figure out how to make both checks pass. The problem is that it is expecting a directory in /var/run, and if I leave it off I get this warning: xrootd-server.i586: W: tmpfile-not-in-filelist /var/run/xrootd please add the specified file to your %files section as %ghost so users can easily query who created the file, it gets uninstalled on package removal and finally other rpmlint checks see it However, if I add it like this: %ghost %{_var}/run/%{name} Or this: %ghost %dir %{_var}/run/%{name} I get the following error: xrootd-server.x86_64: E: dir-or-file-in-var-run (Badness: 10000) /var/run/xrootd A file in the package is located in /var/run. It's not permitted for packages to install files in this directory. How can I set things up to satisfy both rules? The package is here: https://build.opensuse.org/package/show/home:TheBlackCat:branches:science/x… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 12

[opensuse-packaging] Yast not adding repository key
by Jurijs Klopovskis 06 Dec '18

06 Dec '18

Hello! I'm having some troubles creating a package repository to be imported via zypper/yast. I'm able to build RPMs, sign them, produce repodata directory and sign the repomd.xml file. The files: "filelists.xml.gz", "other.xml.gz", "primary.xml.gz", "repomd.xml", "repomd.xml.asc", "repomd.xml.key" are present. The problem arises when I try to add my repo in yast. Upon refresh it complains that repomd.xml is signed with unknown key and that "a trust relationship to the creator of the file cannot be established ". However, as I've stated above, repomd.xml.key file is present in the repodata directory. Is this the file it's supposed to be looking for or am I wrong? Consequently if I continue and add my repo no key is added, like it does say for a Packman repo, and thus package verification fails upon installation. Adding the key manually through yast of with rpm --import fixes the problem. - What am I missing? - What do I have to do for yast to start recognizing the key and offer me to import it? - Is it sane to offer our users to import the key manually? - Any resource to read upon this topic? Some extra info: - Not using OBS for internal reasons. Company policy. - My key is not itself signed, so there is no chain of trust. (I this important in my case?) Any input highly appreciated. Thanks! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 1

[opensuse-packaging] Following upstream git repo with gnulib: "./bootstrap && ./configure && make" without network?
by Bernhard Voelker 05 Dec '18

05 Dec '18

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

2 3

[opensuse-packaging] Problems with packaging systemd.timer
by Eric Schirra 03 Dec '18

03 Dec '18

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

4 6