openSUSE Packaging November 2017

packaging@lists.opensuse.org

45 participants
25 discussions

[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

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging November 2017