April 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] singlespec python and SLE_12_SP2_Backports
by Todd Rme 05 Jul '17

05 Jul '17

In devel:languages:python, the new singlespec approach is causing problems with SLE_12_SP2_Backports build target. The issue is that this build target fails if a package includes files from any package in SLE, and packages that have this problem include some really critical ones like setuptools. This is a problem because in most cases only the python2 versions of the files are available from SLE, but the build failure means the python3 versions do not get published. This results in critical python3 packages needed for singlespec builds not being available. Currently more than half of the packages are either disabled or unresolvable, and that number is going to grow to almost every package as the singlespec conversion continues. The simplest solution would be to just disable that repo by default. However, if there (or could be) some way to selectively disable building python2 versions of specific packages just for that build target it might be better. -- 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] Proposal: Update rpm configuration to fix issues and rationalize configuration
by Neal Gompa 24 May '17

24 May '17

Hello, With some guidance from Michael Schroeder, I'd like to propose a few changes to RPM for Factory / Tumbleweed in time for SLE 15. * Backport the --changes option from RPM git master to rpm 4.13. This is a very simple change that exposes RPM's changelog data with full timestamps. Previously, the commit to support changelogs with full timestamps was backported for reproducible builds work, but the commits for users to access that information easily was not. This is a trivial change, as it merely adds a popt definition and extends the man page to include info on the new parameter. * Change the default binary package payload compression algorithm from old-lzma to xz. Apparently, this change was supposed to have already happened some time ago, but it didn't. This change is simple and brings openSUSE in line with Red Hat Enterprise Linux/CentOS/Fedora and Mageia, as both use xz payloads now. Packages compressed with old-lzma will still be readable by rpm, and even packages compressed with xz will be readable by SLES 12 / OpenSUSE Leap 42 systems. * Define %_sharedstatedir as /var/lib instead of /usr/com. The current path for shared state content (/usr/com) isn't recognized by FHS, whereas /var/lib is recognized as suitable for this purpose, and is currently used as such by Red Hat Enterprise Linux/CentOS/Fedora; Mageia; and Debian/Ubuntu systems. This is expected to be a trivial change, as the /usr/com path has been broken for years and isn't even really used by anything. * Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides rpm to define %_libexecdir as /usr/lib, which leads to pollution of the /usr/lib directory with executable content as well as 64-bit content when there shouldn't be any. This path has been in use on Red Hat Enterprise Linux/CentOS/Fedora and Mageia systems in the Linux world, but has its origins in BSD and is still used today in BSDs and variants (like Mac OS X). The usage of /usr/libexec for libexec content has also finally been recognized by FHS with v3.0, released in 2015. This is a breaking change, as it means that as packages are rebuilt, libexec content *should* migrate from /usr/lib to /usr/libexec. The major advantage of migrating the libexec content is that it will make openSUSE consistent with other major RPM-based Linux distributions, and ease efforts in supporting SLE/openSUSE Leap/openSUSE Tumbleweed alongside Red Hat/CentOS/Fedora by removing the need for hacks and tweaks to support two different hierarchies. With the exception of the --changes backport, all of these proposed changes are geared towards improving compatibility across RPM-based Linux distributions, particularly the two commercial ones: Red Hat Enterprise Linux and SUSE Linux Enterprise. I believe that by doing this, we can make it easier for people to be encouraged to support SLE/openSUSE as a first class platform alongside Red Hat/CentOS/Fedora for FOSS and commercial software. Best regards, Neal -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 29

[opensuse-packaging] Basic question on ruby packaging and build ruby-dependent packages (chef)
by Johannes Kastl 05 May '17

05 May '17

Hi all, I am currently playing with chef, and I found that packages for chef 12 are only built for Tumbleweed. This seems to be due to the required ruby version being too old on Leap and SLE. So to get a newer chef I would have to get a newer ruby on these machines. d:l:r has newer ruby packages, so my question of principle is: Can one built a newer ruby version for, say, SLES11 (or simply linkpac the one in d:l:r) and use this version during building chef12 for SLES11? I guess there would be some prjconf voodoo necessary to get it building, but will these packages be working or is this a general no-go? I found a small note on "multiple ruby version" on the openSUSE ruby packaging page advising to use rvm or docker etc., thus I am asking. Thanks in advance, Johannes P.S.: As the ruby mailinglist seems to be no longer frequented, I am asking on packaging...;-)

2 8

[opensuse-packaging] gfortran cannot link lapack and blas in obs
by Xing 02 May '17

02 May '17

Dear all, I'm packaging a program (gMultiwfn) which uses lapack and blas. It can compile without any problem by using './configure && make install' directly. However when I was packaging it on OBS, the lapcak and blas cannot be found by gfortran and the error is: [ 57s] gfortran -O3 -std=legacy -fopenmp -llapack -lblas -o Multiwfn Multiwfn-Lebedev-Laikov.o Multiwfn-DFTxclib.o Multiwfn-define.o Multiwfn-util.o Multiwfn-function.o Multiwfn-sub.o Multiwfn-fileIO.o Multiwfn-spectrum.o Multiwfn-DOS.o Multiwfn-wfn.o Multiwfn-population.o Multiwfn-compana.o Multiwfn-bondana.o Multiwfn-topology.o Multiwfn-excittransana.o Multiwfn-otherfunc.o Multiwfn-otherfunc2.o Multiwfn-surfana.o Multiwfn-procgriddata.o Multiwfn-AdNDP.o Multiwfn-fuzzyana.o Multiwfn-CDA.o Multiwfn-basinana.o Multiwfn-atmraddens.o [ 57s] Multiwfn-util.o: In function `__util_MOD_diaggemat': [ 57s] util.f90:(.text+0x36a7): undefined reference to `dgeev_' [ 57s] Multiwfn-util.o: In function `__util_MOD_diagsymat': [ 57s] util.f90:(.text+0x3a42): undefined reference to `dsyev_' [ 57s] collect2: error: ld returned 1 exit status [ 57s] Makefile:392: recipe for target 'Multiwfn' failed [ 57s] make[1]: *** [Multiwfn] Error 1 [ 57s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/gMultiwfn-3.3.9-0/build/src' [ 57s] Makefile:356: recipe for target 'all-recursive' failed [ 57s] make: *** [all-recursive] Error 1 [ 57s] error: Bad exit status from /var/tmp/rpm-tmp.bHBPuv (%build) where dgeev_ and dsyev_ are the functions in lapack. Multiwfn-*.o are the obj files just compiled by gfortran. I did require lapack-devel and blas-devel and the -llapack and -lblas options were checked by the configure script (using gcc I think) (Installaton of libblas and liblapack:) [ 14s] [66/107] cumulate libblas3-3.5.0-8.2 ... [ 14s] [68/107] cumulate blas-devel-3.5.0-8.2 ... [ 14s] [84/107] cumulate lapack-devel-3.5.0-8.2 ... [ 14s] [84/107] cumulate lapack-devel-3.5.0-8.2 (checking -lblas and -llapack using gcc): [ 30s] checking for Fortran 77 libraries of gfortran... -L/usr/lib64/gcc/x86_64-suse-linux/4.8 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../.. -lgfortran -lm -lquadmath [ 30s] checking for gcc... gcc [ 30s] checking whether we are using the GNU C compiler... yes [ 30s] checking whether gcc accepts -g... yes [ 30s] checking for gcc option to accept ISO C89... none needed [ 30s] checking whether gcc understands -c and -o together... yes [ 30s] checking for dummy main to link with Fortran 77 libraries... none [ 30s] checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore [ 31s] checking if sgemm_ is being linked in already... no [ 31s] checking for sgemm_ in -lopenblas... no [ 31s] checking for ATL_xerbla in -latlas... no [ 31s] checking for sgemm_ in -lblas... yes [ 31s] checking for dgemm_ in -ldgemm... no [ 31s] checking for sgemm_ in -lmkl_gf_lp64... no [ 31s] checking for sgemm_ in -lmkl... no [ 31s] checking for sgemm_ in -framework vecLib... no [ 31s] checking for sgemm_ in -lcxml... no [ 31s] checking for sgemm_ in -ldxml... no [ 31s] checking for sgemm_ in -lscs... no [ 31s] checking for sgemm_ in -lcomplib.sgimath... no [ 31s] checking for sgemm_ in -lblas... (cached) yes [ 31s] checking for sgemm_ in -lessl... no [ 31s] checking for sgemm_ in -lblas... (cached) yes [ 32s] checking for cheev_... no [ 32s] checking for cheev_ in -llapack... yes [ 32s] checking for a BSD-compatible install... /usr/bin/install -c [ 32s] checking whether build environment is sane... yes [ 32s] checking for a thread-safe mkdir -p... /usr/bin/mkdir -p [ 32s] checking for gawk... gawk [ 32s] checking whether make sets $(MAKE)... yes [ 32s] checking for style of include used by make... GNU [ 32s] checking whether make supports nested variables... yes [ 32s] checking dependency style of gcc... none Really confusing for me...Is there any special caution to use gfortran in OBS? Thanks and best wishes, Xing -- 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] Non-blocking %check
by Todd Rme 01 May '17

01 May '17

There has been some work and advice recently about improving the parallelization of project builds. However, one issue that occurred to me is that a lot of time can be spent running the %check scriptlet that shouldn't have any impact on the final RPMs. My idea was that perhaps the RPM could be used for building packages that depend on it while the %check scriptlet is running. If the %check succeeds, then everything continues as normal. If not, then builds that depend on it are canceled and RPMs that depend on it are invalidated before being published. I understand that this is a big change. In addition to needed big changes in how OSC works, this would also require a fundamental change in the %check macro. It would mean that things that happen during the %check scriptlet would no longer have any impact on the final RPMs. Personally I think this is a feature rather than a bug, I always thought it was strange that tests are allowed to change the package, but it is a big behavior change. I am not sure this is worth the effort to implement or worth breaking existing RPM semantics. But if we are having a problem with the builds not being as parallel as they could be, this might be something at least to consider. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 13

[opensuse-packaging] Requires(pre): user(wwwrun)
by Johannes Weberhofer 26 Apr '17

26 Apr '17

Dear all! When I understand it right, for future builds it is necessary to include systemusers like wwwrun when required. This currently is supported only on Tumbleweed and breaks building on other systems. How can we handle that? Especially if Leap is going back to a 15 version? Please help! -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 5

[opensuse-packaging] Package deletion notice: python-mvpa
by Todd Rme 24 Apr '17

24 Apr '17

python-mvpa no longer builds for any openSUSE release, due to an apparent incompatibility with recent versions of numpy. It seems this package is unmaintained because it was replaced with python-pymvpa2. However, python-pymvpa2 has a different module name (pyvmpa2 vs. pyvmpa) so it will not work with packages that require python-mvpa. I will submit python-pymvpa2 shortly. However, if anyone has any need for python-mvpa (the old version), please fix it. If I haven't received a fix or at least heard anyone commit to doing a fix (and maintaining it longer-term) I will delete the package in one week (on Monday, May 1). -- 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] release-notes-openSUSE requires google-opensans-fonts
by Felix Miata 23 Apr '17

23 Apr '17

TW $SUBJECT can't be right, but trying to zypper rm opensans wants to remove releasenotes. :-( -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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] Distinguishing architectures in spec file leads to failed requirements for required packages that are available
by Thomas Wagner 20 Apr '17

20 Apr '17

Hi! Building encfs requires tinyxml2-3, which is part of Leap 42.2 Tumbleweed but not available for all architectures. There is currently the following condition in the spec file: ... %if 0%{?sle_version}>=120200 || 0%{?suse_version} > 1320 %define os_has_tinyxml2 1 %else %define os_has_tinyxml2 0 %endif ... %if %{os_has_tinyxml2} BuildRequires: tinyxml2-devel %endif ... I changed the condition to a more specific one which contains the corresponding architectures: %if ( 0%{?leap_version}>=420200 && %{_arch} == x86_64 ) || ( 0%{?suse_version} > 1320 && %{_arch} != ppc ) My new condition works and os_has_tinyxml2 is set correctly (output of condition remains the same for unaffected architectures), but later on, I get errors "tinyxml2-devel is needed" for those architectures that definitely have tinyxml2-devel, e.g. all Factory other than ppc and Leap 42.2 x86_64. Why does changing the condition result in a failed requirement, even if the output of the condition is the same? best regards Thomas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0