November 2017 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Selecting GCC version
by Matthias Fehring 03 Apr '18

03 Apr '18

Hello, is there a simple way to force the GCC version used to build a package? openSUSE Leap 42.2 for example uses GCC 4.8 as default compiler, but also provides packages for GCC 5.3. Simply using BuildRequires gcc5 pulls gcc5 in but still uses gcc48 to build the package (especially in Build Service). So is there maybe some Buid Service or spec file switch (bcond) to select the used GCC version? Best greetings Matthias Fehring P.S. Not sure if it is a problem with my browser settings, but when I try to search lists.opensuse.org, it is not possible for me to limit the results to a specific list. Even if I set one, I get results from all lists, what makes searching almost impossible, because most results are commit messages. -- Das Gesetz hat zum Schneckengang verdorben, was Adlerflug geworden wäre. (Friedrich Schiller - Die Räuber) www.buschmann23.de GPG-Key: 0x614C3258 GPG Fingerprint: D786 DDF8 4CA9 00BC CDE0 9A5F CCC5 125D 6E87 D4FC

6 13

[opensuse-packaging] Tumbleweed will change suse_version to 1550
by Dominique Leuenberger / DimStar 01 Dec '17

01 Dec '17

Dear Tumbleweed hackers and packagers, It is about time that openSUSE:Factory aka Tumbleweed moves its suse_version definition up again. There were quite some build hacks in place that were explicitly pinned on 1330, as the idea was to be able to get rid of them by the time we move the version. As this is dragging on for too long though, we changed the hacks to also apply on Tumbleweed with a newer suse_version and all those tweaks are now in place. Which means we can move forward. The new suse_version will be 1550 - starting with December 1st 2017 What's the rationale behind 1550: * SLE15 / Leap 15 are using 1500 (for their entire lifecycle). * Tumbleweed is supposed to be 'ahead of the game', so we plant it between SLe/Leap15 and SLE/Leap16 (don't ask about timeframes for those, nobody knows) While packaging, you should never reference version 1550 though. your thing are compatible to suse_version >= 1500 (meaning all Leap 15.x versions) OR, if something comes into play on newer .x levels, you'd do: %if %{suse_version} > 1500 || %{sle_version} >= 150100 # Feature is available since Leap 15.1 BuildRequires: new-dep %endif This will indicate that starting with 15.1 things are present, and for TW as well. If you don't know yet about the Leap version it might become available, simply skip the sle_version check (but keep the check for suse_version > 1500) The change of suse_version has no visible impact to the end user, this is merely of interest to developers/packagers. Cheers, Dominique

1 1

[opensuse-packaging] Building virtualbox-guest-tools for SLES12: error during loading of kernel-modules
by Johannes Kastl 30 Nov '17

30 Nov '17

Hello guys, I found no package for the virtualbox guest-tools for SLES12, so I decided to try and build it. I took the leap 42.3 virtualbox package and tried to get it to build the tools only. With some fumbling I got it to build: home:ojkastl_buildservice:Virtualbox_guest-tools_SLES12 I tried installing the packages (I am just after the no-X11-tools), which worked. Loading the kernel-modules failed, with an error that might be related to wrong kernel version (or maybe not): > # modprobe --allow-unsupported vboxsf > modprobe: ERROR: could not insert 'vboxsf': Numerical result out of range Same with vboxguest.ko. Same on SP3, SP2 and SP1. As this is the first kmp package I am building, I am puzzled. The error might be due to the fact that the modules are built for kernel 4.4.73, while the machine run 4.4.92. But if I understand the weak-updates links correctly, this should not matter. Or did I build a wrong architecture by disabling the requirements for gcc-32bit and xorg*-32bit (which was the only way I got the package to build, as the guest-tools-x11 needs x11 dependencies obviously). If anyone has a hint or RTFM or can have a look at the spec, this would be highly appreciated. Kind Regards, Johannes

4 5

[opensuse-packaging] Java Building Problems for jing-trang
by Thomas Schraitle 28 Nov '17

28 Nov '17

Hi, as an occasional Java packager I'm trying to package jing and trang. I've create a jing-trang package which lives currently here[1]. However, I seek some expertise from a Java developer. :)) My package builds for Leap 42.2 and 42.3, but does not for Tumbleweed. :-/ The ant process fails, see [2] for an overview. Here is an excerpt from the problem: [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.7. I have a vague idea and searched the Internet for some solutions. It seems, Tumbleweed contains Java 9, but compiling to a previous version needs some other JAR file (rt.jar was mentioned). On the other side, there is an additional error. OBS couldn't find a class although they are found without any problems on Leap 42.2 and 42.3. This is the output: [javac] /home/abuild/rpmbuild/BUILD/jing-trang-20151127/mod/rng-parse/src/main/com/thaiopensource/relaxng/parse/Context.java:3: error: package org.relaxng.datatype does not exist [javac] import org.relaxng.datatype.ValidationContext; How do I solve it? Any idea? Thanks for any pointers or suggestions, much appreciated! :) ---- References [1] https://build.opensuse.org/project/show/home:thomas-schraitle:java/jing-tra… [2] https://build.opensuse.org/package/live_build_log/home:thomas-schraitle:jav… -- Gruß/Regards, Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX GmbH (o< Maxfeldstrasse 5 /\\ Documentation Specialist 90409 Nuernberg, Germany _\_v http://www.suse.com http://lizards.opensuse.org/author/thomas-schraitle/ GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, 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

1 0

[opensuse-packaging] OBS and PPC64 versus PPC64LE ... sometimes build failures
by Dr. Werner Fink 27 Nov '17

27 Nov '17

Hi, I've some trouble with building mksh on PPC64 and PPC64LE. Very often it fails on PPC64 fails with: FAIL ./check.t:heredoc-tmpfile-5 Description: Check that heredoc temp files aren't removed too soon or too late. Backgrounded subshell command with here doc unexpected stdout - first difference: line 1, char 1 (wanted 'A', got 'L' wanted: A hi B Left overs: * got: Left overs: * A hi B sometimes it works perfect. Also I see sometimes a similar defect on PPC64LE at exactly the same check of the test suite of mksh. All build systems seems to be based on qemu/kvm, nevertheless there seem to be some differences but how to detect those (virt-what does report nothing). Maybe it depends on the real host on which qemu-system-ppc64 or qemu-system-ppc64le will be executed. It could be a defect of qemu based on the hosting system. Do we have some real PPC64 and/or PPC64LE irons in our build farm or all hosts based on qemu/kvm? Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

5 6

[opensuse-packaging] Prefered Procedure to Merge Two Packages into One
by Thomas Schraitle 24 Nov '17

24 Nov '17

Hi, currently, I'm facing the problem of how to merge two separate packages into one. In my example, it's the (Java) packages jing and trang. It doesn't make sense anymore to maintain them separately. Upstream develops it in a single repository so it makes sense to do the same in OBS. So my idea was to combine both into a "jing-trang" package project on OBS which creates the two RPM packages jing and trang as output. See [1] for the details. Now, I'm wondering how to proceed. Should I submit the jing-trang to Java:packages first and do a delete request for jing and trang afterwards? Or should there be a bug report at the first place to refer to it in the changelog? What's the preferred procedure here? Thanks! ---- Reference [1] https://build.opensuse.org/package/show/home:thomas-schraitle:java/jing-tra… -- Gruß/Regards, Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX GmbH (o< Maxfeldstrasse 5 /\\ Documentation Specialist 90409 Nuernberg, Germany _\_v http://www.suse.com http://lizards.opensuse.org/author/thomas-schraitle/ GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, 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 4

[opensuse-packaging] scons is going to use python3 as interpreter
by Dominique Leuenberger / DimStar 24 Nov '17

24 Nov '17

Dear Tumbleweed hackers and packagers, As you all know, python3 is 'the new thing' and pytho2 is being moved to the background. Various packages have already been switched to be using python3 - probably 'the easy ones' are all done. so we enter the jounery of more complex things. One such package is scons, which has been switched to be using python3 in request https://build.opensuse.org/request/show/542087 Now, scons is a bit 'special', as it is written in python and is basiclaly compatible to python2 AND python3, BUT it parses SConstruct/SConscript of different packages. And there the results are a bit mixed when it comes to python3 compliance Martin setup a test branch where he monitors all packages in openSUSE:Factory using scons as their build script, see https://build.opensuse.org/project/monitor/home:pluskalm:python3 Out of those only two packages are tracked as part of the rings (ffado and gpsd), which means from a Factory process perspective, once those two are fixed, the scons-switch to python3 could happen. As this will impact some other packages, I'd like to ask for your help to fix the other failing packages there. Simply branch them using "osc branch openSUSE:Factory $pkg" and submit them back to their original devel project. Martin's project only serves as monitor and should not receive submissions. In many cases, the issue in SConstruct are the usual python3 offenders: print "FOO" needs to be written as print ("FOO") now; so patches can turn out to be easy (in some cases they are more complex though) This mail serves as an info so you won't be surprised when scons is being merged and some packagaes stop building (of course some people will still be surprised, but such is life) Cheers Dominique

4 5

[opensuse-packaging] Action-Required for Packagers re: /var/adm/fillup-templates move
by Richard Brown 23 Nov '17

23 Nov '17

Hi Packagers, As previously discussed on the opensuse-packaging mailinglist, we are moving our location of fillup-templates from /var/adm to /usr/share https://lists.opensuse.org/opensuse-packaging/2017-11/msg00017.html In order to do this as smoothly as possible we are using a new %_fillupdir macro so spec files can inherit the new location, while still defining the macro as the old location for older distributions to not change anything there. https://en.opensuse.org/index.php?title=openSUSE:Packaging_Conventions_RPM_… As promised, this is the official notification that the new %_fillupdir macro is now present in Tumbleweed and should be used in all specfiles instead of /var/adm/fillup-templates The original plan was going to require all package maintainers to modify their specfiles to use the new macro. However, while taking care of the packages I am interested in for Kubic I decided to do the work for all 207 affected packages. So package maintainers, all you should have to do is review & accept the OBS Submit Requests from me referencing boo#1069468, the tracker bug for this issue. The submit requests include the compatibility definition for older distributions. Feel free to remove it if you do not need to build that package for older distributions. Please do what you can to accept and forward these requests to factory as quickly as possible, especially for those packages also used by SLE & Leap. I am hopeful to get the btrfs subvolumes simplified once these changes are complete, so I need your help to get these done promptly. Thanks in advance, -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] nscd not updated/restarted soon enough during zypper dup
by Olaf Hering 23 Nov '17

23 Nov '17

During upgrade of postfix, nscd did not work properly because some symbols are not available. I wonder what needs to be done to make nscd available earlier during 'zypper dup'. The %pre/%post scripts in postfix do not use it directly, but the used getent/useradd/... binaries may try to use it. The Requires(pre/post) in postfix.spec are apparently ok, except the incorrect conditional for getent. glibc was upgraded before postfix, so this is not the issue here. Upgrade was blocked by various bugs in the last months, they got fixed only until very recently. Thats the reason for the huge jump forward. Olaf root@optiplex:~ # grep -E '(release-ftp|nscd|postfix|glibc)' /var/log/zypp/history 2017-05-30 09:29:56|install|linux-glibc-devel|4.11-1.1|noarch||oss|4e6cc97a31d9aa568a3d7966364eb0fac76ac5d4| 2017-05-30 09:30:33|install|openSUSE-release-ftp|20170524-1.1|x86_64||oss|8a907ed01f6f4d4ba30fc23484e222b605ef8b6c| 2017-11-23 09:26:35|install|glibc-debuginfo|2.26-7.1|x86_64||debug|d2a3893b076e3d0b50116a8f0bcd992ab5016b43| 2017-11-23 09:26:37|install|glibc-debugsource|2.26-7.1|x86_64||debug|4562bbb692a9d7a50554eaab6bed54ec1fbc7e6b| 2017-11-23 09:34:19|install|postfix-debuginfo|3.2.4-2.1|x86_64||debug|396a383e4310daeb766a9d2aa22e8f2b27a656a4| 2017-11-23 09:34:19|install|postfix-debugsource|3.2.4-2.1|x86_64||debug|8aea6966b0a34e1d406587048b84c1b5fac1b124| 2017-11-23 09:39:44|install|nscd-debuginfo|2.26-7.1|x86_64||debug|59888b3af71ece2c8f016f267f335944a759affe| 2017-11-23 09:39:46|install|glibc-locale-debuginfo|2.26-7.1|x86_64||debug|247d10317153d3d719fd2066722235ccb71cb59a| 2017-11-23 09:39:46|install|glibc-extra-debuginfo|2.26-7.1|x86_64||debug|3b582b7085c7298b92a484f67d5fc7ab1df846e7| 2017-11-23 09:43:45|install|openSUSE-release-ftp|20171121-1.2|x86_64||oss|4df1420c4ec3f828ac975fe628bf14cddf8e8b9b| # 2017-11-23 09:44:07 glibc-2.26-7.1.x86_64.rpm installed ok 2017-11-23 09:44:07|install|glibc|2.26-7.1|x86_64||oss|dc1094b037c47c4244925d4609a18bbb79b504f8| 2017-11-23 09:44:50|install|glibc-locale|2.26-7.1|x86_64||oss|ab520862fe10de2be7f4b6c1a07c222e0de80a2e| 2017-11-23 09:45:24|install|glibc-32bit|2.26-7.1|x86_64||oss|8a1923d118bce00891b0a08df236aa832c1a5613| 2017-11-23 09:45:41|install|linux-glibc-devel|4.14-1.1|noarch||oss|03f07945f92efe01b28148e764c002e23b6f3ae7| 2017-11-23 09:46:40|install|glibc-locale-32bit|2.26-7.1|x86_64||oss|e0d925fdeb68ea286cd6b82e3527672f7bb7c9cb| # /etc/permissions.d/postfix # 2017-11-23 09:59:15 postfix-3.2.4-2.1.x86_64.rpm installed ok # nscd: relocation error: nscd: symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference # nscd: relocation error: nscd: symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference # warning: /etc/postfix/main.cf created as /etc/postfix/main.cf.rpmnew # /etc/postfix/postfix-files /etc/postfix/postfix-script # /etc/postfix/post-install # Updating /etc/sysconfig/postfix ... 2017-11-23 09:59:15|install|postfix|3.2.4-2.1|x86_64||oss|a1060870bc514f36d2f8426676227c27acb348ff| 2017-11-23 09:59:18|install|nscd|2.26-7.1|x86_64||oss|96365fe546123d842c94c0118ab60000c4075094| 2017-11-23 10:02:33|install|glibc-extra|2.26-7.1|x86_64||oss|25f1fa538db1d690d43e797a59de69a45e4e4876| 2017-11-23 10:02:36|install|glibc-devel|2.26-7.1|x86_64||oss|e68c0735b0c1f603649f3a85cc8e912fcdd574a2|

2 5

[opensuse-packaging] Who or what disabled the openSUSE_Factory repo in obs://home:seife:testing?
by Stefan Seyfried 22 Nov '17

22 Nov '17

(Cross-posting, because I don't know if this is an OBS problem or another crazy policy) Today I found that my packages in home:seife:testing are almost all gone, which prevented my daily "zypper -v dup --no-r --no-allow-vendor-change" from completing successfully. https://build.opensuse.org/project/show/home:seife:testing All but one package in the Factory repo are "excluded" and apparently there's no way to include them again. How do I fix that? -- 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 5

[opensuse-packaging] Deprecation of /var/adm/update-scripts
by Thorsten Kukuk 22 Nov '17

22 Nov '17

Hi, if you never heard of /var/adm/update-scripts and your packages are not using it, you can ignore this. In the good old times, libzypp wasn't able to handle RPM %posttrans scripts correct (which shows, that the old times were not always good ;) ). A workaround for this was to use update-scripts. Since some years (SLE12) libzypp supports now RPM %posttrans scripts, so there is no need anymore to use update-scripts as workaround. The maintainers would like now to remove support of /var/adm/update-scripts from libzypp. Why? Because it creates a lot of additional efford for everybody. You have to implement everything twice (once for RPM, once for libzypp) and test everything twice. And since this is so much work, a lot of developer don't do that, which leads to bugs depending on how you install or update a package. So, if you use update-scripts as RPM %posttrans replacement, please change your spec files to only use RPM %posttrans scripts. If you need update-scripts for something else and you cannot remove it, please speak up now. But you should have a good answer to "what does happen if your package is installed or updated with plain rpm?". Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- 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] how to fix build fail
by Christian 20 Nov '17

20 Nov '17

Hi, trying to build gstreamer-plugins-bad on my instance, but running into the following error and have no idea how to fix. [ 463s] + %make_build [ 463s] /var/tmp/rpm-tmp.GscvOa: line 62: fg: no job control [ 463s] error: Bad exit status from /var/tmp/rpm-tmp.GscvOa (%build) [ 463s] [ 463s] [ 463s] RPM build errors: [ 463s] Bad exit status from /var/tmp/rpm-tmp.GscvOa (%build) [ 463s] [ 463s] s4y-01 failed "build gstreamer-plugins-bad.spec" at Sat Nov 18 19:44:25 UTC 2017. [ 463s] having it for 42.2 and 42.3 Thank you :) -- Christian ------------------------------------------------------------ https://join.worldcommunitygrid.org?recruiterId=177038 ------------------------------------------------------------ http://www.sc24.de - Sportbekleidung ------------------------------------------------------------ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 10

[opensuse-packaging] RFC: Relocation of /vad/adm/fillup-templates
by Richard Brown 17 Nov '17

17 Nov '17

Hello Packagers, As part of my ongoing efforts to simplify our /var subvolume complexity, the next target on my list is /var/adm/fillup-templates As they are not variable data (meaning they shouldn't be in /var at all) nor log data (meaning they shouldn't be in /var/adm), I wish to relocate all of these fillup-templates to /usr/share/fillup-templates This will of course require changes in a lot of .spec files Therefore I am doing my best to make the transition as painless as possible for both our users and packages I am proposing changing the fillup macros (eg. %fillup_only, %fillup_and_insserv) to use both the new location, and if a template is not found in the new location then fallback to the old location. This means while obviously I would like to see this transition be as short as possible, we will not _need_ to move every specfile reference to /var/adm/fillup-templates in one coordinated jump The new path of /usr/share/fillup-templates will be implemented as a new rpm macro called %_fillupdir Once the macro is present in our rpm package, packagers will need to replace references to /var/adm/fillup-templates with %_fillupdir I will announce when this is the case in both this list and -factory; You can also expect me to contribute a significant number of the changes to packages myself, but I can't do it all alone, so your help will be GREATLY appreciated. OBS Project administrators who want to continue support building packages referencing this macro in versions of our distributions that don't carry it in their rpm package will need to add the following to their OBS PrjConf: %if ! %{defined _fillupdir} %define _fillupdir /var/adm/fillup-templates %endif This will allow those packages to build on those older distributions, as they do today, using the old /var/adm/fillup-templates location The proposed rpm macro and filesystem changes are currently visible in my home project here: https://build.opensuse.org/package/rdiff/home:RBrownSUSE:branches:Base:Syst… https://build.opensuse.org/package/rdiff/home:RBrownSUSE:branches:Base:Syst… Does anyone have any thoughts, comments, or most importantly, well reasoned objections before I submit these to Base:System and get this ball moving? Regards, -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 9

[opensuse-packaging] New thoughts on python singlespec macros
by Todd Rme 16 Nov '17

16 Nov '17

Thinking about what we need for python3 conversion long-term, a few issues have come to mind that currently aren't addressed well in the macros or previous discussions: 1. We really need to get rid of using unversioned "python" in shebangs. 2. We need to switch everything over to use versioned rpm names (particularly "python2-foo"), while still supporting older SLE/Leap versions. 3. We need to be able to handle builds that don't include python2. 4. pytest often checks the directories being used, which breaks when using "%python_expand" Regarding 1, there are currently two pain points. First and most obvious is the fact that the shebangs have to be edit manually. The second is that if we want versioned shebangs, we need to manually recompile the files to avoid mtime issues. Ideally changing the shebangs could be handled automatically during %python_build, but there could still be a separate macro that could be called in cases where manual changes are necessary. Recompiling is needed in other situations as well, so having a macro to handle that would be useful in general. Regarding 2, this is more of a policy issue. I think all packages, even python2-only ones, should be switched over to using singlespec. This makes sure that they have the correct name on all platforms. Backports packages should have a conditional "skip_python3" that is set to disable building for python versions equal to or greater than the version they were backported from, even when those versions are no longer shipped by openSUSE. There should also be a policy that, when an upstream package drops python2 support, the last-supported python2 version should be made available in the "python2-foo" package. Only "python-foo-doc" and "python-foo-data" can have the unversioned "python-" name, and that is only for version-independent documentation and assets, respectively. Regarding 3, there are again two main pain points. The first is that there is no macro I am aware of to reliable determine if a given python version is being built. %have_python2 and %have_python3 no longer work reliably AFAIK. The second is that build dependencies for particular python versions cannot be reliably disabled if that python version is not built. Currently most packages that have a python2-only build dependency just unconditionally require it, which means it will be pulled in even if python2 builds are disabled. Ideally I would like to see "%{python2_module foo}" and "%{python3_module foo}" that will only pull in that dependency if that version of python is being used. This also has the advantage of not needing to care about backwards-compatibility issues of "python-foo" vs. "python2-foo" names, which is handled inconsistently right now. If that is not feasible, just having a reliable check would be an improvement. Regarding 4, I don't really understand what "%python_expand" is doing behind the scenes, and whether there is a simple workaround or whether the macro needs to do something different internally. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 9

[opensuse-packaging] rubygem build: macro expansion error
by Hans-Peter Jansen 16 Nov '17

16 Nov '17

Hi, I suffer from macro expansion errors in rubygem builds: [ 29s] + exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --nosignature --define '_build_create_debug 1' --define 'disturl obs://build.opensuse.org/home:frispete:GitLab/openSUSE_13.2/cd8f1e1e66ffd44…' /home/abuild/rpmbuild/SOURCES/rubygem-addressable.spec [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. [ 29s] error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. resulting in build errors later on similar to: [ 31s] error: Failed build dependencies: [ 31s] rubygem(ruby:2.1.0: is needed by rubygem-addressable-2.5.2-2.1.x86_64 [ 31s] rubygem(ruby:2.2.0: is needed by rubygem-addressable-2.5.2-2.1.x86_64 [ 31s] rubygem(ruby:2.3.0: is needed by rubygem-addressable-2.5.2-2.1.x86_64 [ 31s] rubygem(ruby:2.4.0: is needed by rubygem-addressable-2.5.2-2.1.x86_64 [ 31s] rubygem(ruby:2.5.0: is needed by rubygem-addressable-2.5.2-2.1.x86_64 https://build.opensuse.org/package/live_build_log/home:frispete:GitLab/ruby… The ruby packages in question are built here: https://build.opensuse.org/project/monitor/home:frispete:ruby I slightly modified the macros of devel:languages:ruby for the later versions running on top of openSUSE_13.2. (yes, lame, I know..) Any idea, how to debug such macro expansion errors? Is there a way to examine the expanded spec? I can workaround these problems by pre-installing the offending ruby packages, but that's just papering over the underlying problem, that I would like to understand. 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 1

[opensuse-packaging] systemsmanagement:puppet has no bugowner
by Mathias Homann 13 Nov '17

13 Nov '17

systemsmanagement:puppet has no bugowners, and when one tries to file a bug on bugzilla one gets this: Assignee: *jatan11@please-enter-an-email-address* did not match anything Can someone please see to that? Cheers MH -- Mathias Homann Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann(a)openSUSE.org http://www.tuxonline.tech gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

2 2

[opensuse-packaging] .changes madness with upstream updates
by Michael Ströder 13 Nov '17

13 Nov '17

HI! Sometimes a submission of me gets declined because of changelog being too short or too long referring to this policy: https://en.opensuse.org/openSUSE:Creating_a_changes_file_%28RPM%29#What_goe… While the guide-lines were surely outlined with good aims I have to question the current policy of package changelogs (*.changes) regarding upstream updates. The rules are too blurry and boil down to "Do the right thing". I don't like to provide an extract of an upstream changelog because I'm convinced that no packager is capable of extracting a really meaningful essence from an upstream changelog. Furthermore I assume that upstream developers are also lazy writing docs and the changelog would have been already shorter if still meaningful. So IMO the right way is to.. 1. just mention upstream release and packaging changes xor 2. add the complete changelog. Ciao, Michael.

14 18

[opensuse-packaging] Java-build on TW fails suddenly: [javac] error: Source option 1.5 is no longer supported. Use 1.6 or later.
by Axel Braun 12 Nov '17

12 Nov '17

Hi, maybe we have a Java-Expert around that can support: projectlibre [1] suddenly fails to build on TW, with the error message: [ 31s] [ 31s] init: [ 31s] [mkdir] Created dir: /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build [ 31s] [mkdir] Created dir: /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/tmp [ 31s] [ 31s] build: [ 31s] [javac] /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build.xml:30: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [ 31s] [javac] Compiling 10 source files to /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build [ 31s] [javac] error: Source option 1.5 is no longer supported. Use 1.6 or later. [ 31s] [javac] error: Target option 1.5 is no longer supported. Use 1.6 or later. [ 31s] [ 31s] BUILD FAILED As the version setting is not explicit mentioned in the spec file I guess it is some implicit definition. Anyone an idea where to look forß Thanks Axel [1] https://build.opensuse.org/package/show/Office/projectlibre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 8

[opensuse-packaging] pycrypro unmaintained, what to do about fork pycryptodome
by Todd Rme 11 Nov '17

11 Nov '17

pycrypro [1] is an important package, used by a wide variety of python packages for cryptography. It is also totally unmaintained, having seen no releases or commits since 2014. There is a well-maintained fork that uses the same namespace, pycryptodome [2]. However, although it is the same in most cases, there are a few places where the API differs [3]. And although it is mostly backwards-compatible, it is not forwards-compatible, adding a bunch of new APIs that packages that depend on it directly may use. The problem is that more and more packages are now depending directly on pycroptodome rather than pycrypto at install time, and since the two use the same namespace they are not co-installable, so trying to install a package that depends on it results in conflicts with large parts of the python software stack. So we need to make a decision how we are going to handle the situation. The simplest, but also riskiest, solution would be to have the pycroptodome package provide/obsolete pycrypto, and have package that require the old API depend on the old pycrypto version number (so pycrypto < 3). But I doubt all of these packages have unit tests, which means we could have breakage. The most difficult solution would be to manually check each package for compatibility with pycryptodome and switch to it explicitly. The intermediate solution would be to have pycrypto and pycryptodome provide some other name, and have the packages depend on that name but prefer pycrypto. This means, however, that installing a package that requires pycryptodome specifically could suddenly cause packages you installed previously to break. We ran into a similar situation with the PIL/Pillow fork, but that had the issue where PIL never supported python3, and at least at the time more care seemed to be taken to maintain backwards-compatibility. 1: https://pypi.python.org/pypi/pycrypto/ 2: https://pypi.python.org/pypi/pycryptodome/ 3: https://www.pycryptodome.org/en/latest/src/vs_pycrypto.html -- 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] Re: Questioning systemd tmpfiles.d packaging guidelines
by Thorsten Kukuk 09 Nov '17

09 Nov '17

On Thu, Nov 09, Franck Bui wrote: > On 11/08/2017 09:44 AM, Thorsten Kukuk wrote: > > > > So my problems: > > > > 1. We call systemd-tmpfiles with the full path to the tmpfiles > > configuration. And this is documented in this way in our wiki, too. > > But: if I read the manual page correct, this is the wrong way. If > > you specify the full path to the config file as argument, adjusted > > configuration files in /etc done by the sysadmin are ignored. > > Why do we force every packager to ignore changes made by the admin > > here? > > I must admit that I can't think of a useful case where the admin would > need to overwrite the tmpfiles shipped by a package. You seem to have > found a case but unfortunately you haven't provided any details on it so > it's hard to tell. I don't have a specific case, I did only read the manual page and found a mismatch with what we are doing. Since the systemd manual pages and other Distributions like Fedora explicit mention that you can overwrite the tmpfiles, we should not "forbid" that for no good reason. But if I look at read-only root filesystem, transactional-updates and clusters, I can imagine some situations, where it could be quite handy if you have the possibility to overwrite tmpfiles. Thorsten > OTOH since tmpfiles can be overwritten, there're probably some cases > where it makes sense. If so we shouldn't use and advice to use absolute > paths indeed. -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

Re: [opensuse-packaging] systemsmanagement:puppet has no bugowner
by Adrian Schröter 09 Nov '17

09 Nov '17

On Mittwoch, 8. November 2017, 19:21:33 CET wrote Vojta Dziewiecki: > Hello, > Kristýna replaced me as the package maintainer about 3 years ago. You can > remove me, as I am not willing to work on the package in my free time > anyway. It is the best when you remove yourself then. thank you adrian > 2017-11-07 9:07 GMT+01:00 Adrian Schröter <adrian(a)suse.de>: > > > On Dienstag, 7. November 2017, 09:01:02 CET wrote Mathias Homann: > > > systemsmanagement:puppet has no bugowners, and when one tries to file a > > bug on > > > bugzilla one gets this: > > > > > > > > > > > > Assignee: > > > *jatan11@please-enter-an-email-address* did not match anything > > > > > > > > > Can someone please see to that? > > > > The project has multiple bugowners, not a good idea anyway. > > Using a group would make more sense here. > > > > However, I have removed the first entry with an invalid email > > adress now, so the next person will be taken. > > > > Kristyna, Nanuk, Theo, Wojtek, you could create some mailing > > list somewhere and we could found a group if you want > > to have multiple official bugowners. > > > > Otherwise Kristyna will get the bugzilla reports now ;) > > > > -- > > > > Adrian Schroeter > > email: adrian(a)suse.de > > > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB > > 21284 (AG Nürnberg) > > > > Maxfeldstraße 5 > > 90409 Nürnberg > > Germany > > > > > > > > > -- Adrian Schroeter email: adrian(a)suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Questioning systemd tmpfiles.d packaging guidelines
by Thorsten Kukuk 08 Nov '17

08 Nov '17

Hi, background: with Richards move of the rpm db to /usr, we are now looking at and cleaning up the content and subvolume mess in /var. And, if you take snapshots, rollback and transactional-updates serious, not everything in /var is accessible during upgrade. A solution for some of the problems is tmpfiles.d. So I converted two packages as PoC to use tmpfiles.d, and it works fine, except that rpmlint now reports a lot of policy violations. And I'm questioning, if this checks are really correct or what the idea behind this was. So my problems: 1. We call systemd-tmpfiles with the full path to the tmpfiles configuration. And this is documented in this way in our wiki, too. But: if I read the manual page correct, this is the wrong way. If you specify the full path to the config file as argument, adjusted configuration files in /etc done by the sysadmin are ignored. Why do we force every packager to ignore changes made by the admin here? 2. We tell the packager to add %ghost entries for every file, so that rpm -qf works. I can understand the reason, but in my experience, this %ghost entries always create problems later during update or deinstallation. Additional, rpm tries to mess around with this files during update/de-installation, but not always this files are accessible at this time. And if I can add the files to the package list, in most cases I don't need tmpfiles.d, but could add them directly to the file list. My dream: rpm -qf is looking at tmpfiles.d, if it does not find the file in the RPM database. Knowing that tmpfiles is creating this file and which configuration file is much, much more helpfull! I would like to see at least the full path to the configuration file changed to only the name of the configuration file. And maybe somebody has a better idea how to track tmpfiles.d config file changes except %ghost entries in RPM. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Status of devel:languages:perl:CPAN-* repositories?
by Bjoern Voigt 07 Nov '17

07 Nov '17

I branched and fixed the package perl-grepmail from devel:languages:perl:CPAN-G repository: https://build.opensuse.org/package/show/home:bjoernv:branches:devel:languag… But as I wanted to submit the package I got the following error message: "Unable to submit: The target project devel:languages:perl:CPAN-G is not accepting requests because: If you want to fix a package - submit it to devel:languages:perl" In devel:languages:perl there is no such package. What is the correct update process here? Greetings, Björn -- 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] RFC: changing RPM's default scriptlet locale
by jan matejek 06 Nov '17

06 Nov '17

Fellow mortals, more and more packages need their locale to be set to something more sensible than C. This hit me while switching packages over to Python 3. Python gets its encoding from locale, so by default, it won't decode UTF-8 unless the appropriate encoding is set. Right now, when gtk-doc is switched to use Python 3, it won't build UTF-8 documentation. This could be changed in gtk-doc itself (although that is impractical), but perhaps a better way is to change the default locale for spec scriptlets. Right now the macros set it to C. We could switch that to "C.UTF-8", "en_US.UTF-8", or export a special RPM variable that could be overriden in your spec file. Still, the default should be something with UTF-8 in it. I'm now trying to build a Ring 1 staging project with this change. So far I have seen one failure related to it: with en_US.UTF-8, bash ranges (like [a-z]) are case-insensitive and match more than intended. That could be solved by changing the expression, or by setting locale to C.UTF-8. Thoughts, comments? regards m.

7 16

[opensuse-packaging] Python 2/3 and update-alternatives
by Thomas Schraitle 06 Nov '17

06 Nov '17

Hi, I'm wondering, why the python packages for version 2 and 3 don't use the update-alternatives script. Any reason for this? I haven't found anything in the package itself nor on mailing lists. Probably I've missed some. Maybe this was on purpose as Python2 isn't a complete replacement for Python3 (and vice versa). On the other side, I assume, not all Java runtime environments are always compatible. However, still, you can use this: # update-alternatives --display java java - auto mode link best version is /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java link currently points to /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java link java is /usr/bin/java [...] # update-alternatives --display python update-alternatives: error: no alternatives for python (executed on openSUSE Tumbleweed) Bug? Feature? Design decision? Hope someone can enlighten me. :)) Thanks! -- Gruß/Regards, Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX Products GmbH (o< Maxfeldstrasse 5 /\\ Documentation Specialist 90409 Nuernberg, Germany _\_v http://www.suse.com | HRB 21284 SUSE LINUX GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, 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

4 4