May 2017 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] important: to all devel:languages:python package maintainers
by Todd Rme 03 May '17

03 May '17

You may have received an email from me yesterday regarding your status as a python package maintainer. As part of a general cleanup of openSUSE's python packages, we are checking whether the maintainers of packages in devel:languages:python would like to continue in that role. This email is being sent to all maintainers, even devel:languages:python project maintainers, regardless of how active they have been. It is not meant to reflect on anyone's contributions. Note that perfectly fine to choose to remain maintainer of some packages but not others. The following email addresses have been marked undeliverable: bwhiteley(a)novell.com gber(a)opensuse.org iartarisi(a)suse.com jkeil(a)suse.com thoenig(a)suse.com timlee(a)novell.com saschpe(a)opensuse.org If one or more of these email addresses belongs to you, please contact me. Also, if you think you may be the maintainer of a devel:languages:python package and haven't received an email, please double-check your status. If we have not heard back from someone in two weeks (Tuesday, May 16), we will assume that person is no longer interested in being a maintainer. Changes to maintainer status are not necessarily permanent. If you miss one of these email messages or change your mind at a future date, you can request the maintainer role again with a note about your previous maintainer status. Thank you for your time and hard work. Sincerely, Todd -- 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] 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