May 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] python singlespec: iterating over all binaries
by Sebastian 01 Jun '17

01 Jun '17

Hi, As I needed a singlespec-conversion of python-requests-mock I tried to do that. But this package uses "testrepository" for the checks. This requires the python program to use in a configuration file. This is one line of such a .testr.conf file: > test_command=python -m subunit.run discover requests_mock $LISTOPT $IDOPTION I can easily replace 'python' with e.g. 'python3' with sed: > sed -i 's/python/python3/' .testr.conf > testr init > testr run --parallel It works, but it's not a nice solution and can break in the future. So I'd somehow need to "iterate" over all available python-binaries. Currently with python2 and python3 I can hardcode it. Using %python_expand does not work here because it calls the interpreter along with a lot of other commands, I'd just need the last line of that macro. Looking a the macro definitions - without knowledge how they work - I couldn't find out how I could extract that. Is there a good way to that better? Or if not - is it ok to leave it as it is? Here is the package: https://build.opensuse.org/package/show/home:sebix:branches:devel:languages… Sebastian -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers

2 2

[opensuse-packaging] Publishing disabled on KDE:Qt5 and KDE:Applications
by Mathias Homann 29 May '17

29 May '17

...or in other words, anyone who uses those repositories wlll basically break his installation with "zypper dup". Can someone please enable publishing on KDE:Qt5 and KDE:Applications? I filed some bugs on bugzilla but there has been no rection from the assignee. Thanks. -- 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] Noarch package, with arch-specific subpackage
by Robert Munteanu 29 May '17

29 May '17

Hi, I'm trying to package Maven 3.5.0 in devel:tools:building . One change brought by this version is that it packages two .so files for native console support. Being a Java program, the package was built as noarch so far. Now I would like to keep most of the package as 'noarch' and package the arch-specific bits in subpackages. But I have no idea how to do that :-) If I keep the main package as 'noarch' and define a subpackage, the subpackage will be noarch as well. If I try to manually define an architecture for the subpackage using BuildArch: %{_arch} rpmbuild complains that [ 2s] error: line 57: Only noarch subpackages are supported: BuildArch: x86_64 Is there a way of building a NoArch main package with a arch-specific subpackage? Thanks, Robert -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] Long-failing python packages
by Todd Rme 25 May '17

25 May '17

The following packages in devel:languages:python are failing across the board, have been failing for Factory for at least 2 years as far as I can tell, not been updated upstream for at least 2 years, and the way to fix them is not obvious to me: python-django-projector python-meep python-mezzanine If anyone needs these, please fix them. I will remove them in two weeks (by Thursday, June 1) if no one has let me know they plan to fix them. -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] no more nobody user on OBS?
by Ruediger Meier 25 May '17

25 May '17

Hi, seems that Tumbleweed and Factory has no more user "nobody" defined in /etc/passwd. Is this wanted? cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 16

[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

Re: [opensuse-packaging] no more nobody user on OBS?
by Ruediger Meier 24 May '17

24 May '17

On Wednesday 24 May 2017, Bernhard Voelker wrote: > On 05/23/2017 05:35 PM, Dominique Leuenberger / DimStar wrote: > > That is indeed wanted - the list of users has constantly been > > growing and for many users/groups, it is/was not clear what > > requires them. > > While reducing (or better saying: letting the packages choose) is > good for the final product, how could we get some of them back on > OBS? > > Some tests rely on having a 2nd user - e.g. the coreutils-testsuite > would not have to SKIP a couple of tests. (BTW: it'd be great if > abuild could be member of a second group for some of these tests). > > ... > [ 102s] basic.sh: skipped test: requires membership in two groups > [ 102s] SKIP: tests/chgrp/basic.sh > ... > [ 119s] default-no-deref.sh: skipped test: requires membership in > two groups [ 119s] SKIP: tests/chgrp/default-no-deref.sh > [ 119s] deref.sh: skipped test: requires membership in two groups > [ 119s] SKIP: tests/chgrp/deref.sh > [ 119s] no-x.sh: skipped test: requires membership in two groups > [ 119s] SKIP: tests/chgrp/no-x.sh > [ 119s] posix-H.sh: skipped test: requires membership in two groups > [ 119s] SKIP: tests/chgrp/posix-H.sh > [ 119s] recurse.sh: skipped test: requires membership in two groups > [ 119s] SKIP: tests/chgrp/recurse.sh > ... > [ 286s] acl.sh: skipped test: This test requires a local user named > bin. [ 286s] SKIP: tests/cp/acl.sh > ... > [ 286s] existing-perm-race.sh: skipped test: requires membership in > two groups [ 286s] SKIP: tests/cp/existing-perm-race.sh > ... > [ 304s] acl.sh: skipped test: This test requires a local user named > bin. [ 304s] SKIP: tests/mv/acl.sh > ... > [ 332s] # TOTAL: 563 > [ 332s] # PASS: 496 > [ 332s] # SKIP: 67 > > Idea: could we create/have some packages doing such modifications in > the build environment via BuildRequires, but which are never shipped > to regular systems? ... actually like the abuild user? You can add +%if 0%{?suse_version} > 1320 +BuildRequires: user(nobody) +%endif However it's just annoying that we have to do that and endusers of the distro also have to do that. Probably a user would just use useradd to create the missing user manually with random id and group, conflicting to the definitions of system-user-nobody's /usr/lib/sysusers.d/system-user-nobody.conf So the goal to clean-up and well-define our system users leads to more randomization. I still see no benefit of not providing "daemon" and "nobody" always in opposite to basically any other existing Linux distro. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

Re: [opensuse-packaging] no more nobody user on OBS?
by Dominique Leuenberger / DimStar 24 May '17

24 May '17

On Wed, 2017-05-24 at 09:25 +0200, Ruediger Meier wrote: > However it's just annoying that we have to do that and endusers of > the > distro also have to do that. Probably a user would just use useradd > to > create the missing user manually with random id and group, > conflicting > to the definitions of > system-user-nobody's /usr/lib/sysusers.d/system-user-nobody.conf an end-user trusting your package gets the user as a dependency.. why would he have to create the user? You as packager should know what your package requires - what user it relies on and what not. >

3 2

[opensuse-packaging] Build-Dependencies in SPEC-File
by Andre Herrlich 23 May '17

23 May '17

Hi All, I'm currently creating a SPEC file for an application written in GO. I have the problem that some of the Build-Requirementes can not be served from the standard repositories. On my local system, I can add appropriate repositories (from the opensuse build service) for that. How does this work with an automated build on build.opensuse.com? Just a BuildRequires go>=1.8 and the build service finds the dependencies automatically? Bye, Andre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] RFC: Removing python-imaging from devel:languages:python
by Todd Rme 23 May '17

23 May '17

The python-imaging package (callled "Pil" upstream) has been unmaintained for over 7.5 years. It was never ported to python3. Further, there is a generally drop-in-compatible fork, Pillow, that is actively maintained and is compatible with Python3. On top of that its name violates openSUSE python packaging guidelines (its proper name should be "python-Pil"). I think it is time we go ahead and drop python-imaging entirely. All packages are currently configured to use python-Pillow in place of python-imaging. Further, python-imaging is not in openSUSE:Factory while python-Pillow is. I am a bit hesitant to drop unmaintained but still-functional python packages, but in cases where there is a well-maintained drop-in replacement like this I don't see a benefit to our users to keeping it, while it wastes build cycles and can lead to confusion. And the reason I am bringing this up now is because it is causing some build conflicts related to the singlespec conversion. However, there are a few home: packages that link to python-imaging. If we drop the package, I want to give fair warning so anyone who wants it can break the link and keep it themselves. If there are no objections, I will delete the package in one week, on Monday, May 29. -- 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] Hybrid singlespec package
by Luigi Baldoni 21 May '17

21 May '17

Hi everyone, I need to package a python module that's currently built via makefile and can't be single-specced for every target. I've tried adding singlespec tags inside conditionals, but I ended up seeing error messages on both ends. Do you see a way around creating a new package and enabling it only for newer distros? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/Hybrid-singlespec-package-tp5087080.html Sent from the opensuse-packaging mailing list archive at Nabble.com. -- 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] Need help with missing 'pyuic4' and the python-modules 'dbus' and 'PyQt4'
by Dave Plater 16 May '17

16 May '17

Hi, I've just been notified of a build failure of Factory/ffado-mixer which is due to this: [ 67s] Checking whether 'which pyuic4' executes no [ 67s] [ 67s] The prerequisites ('pyuic4' and the python-modules 'dbus' and 'PyQt4', the [ 67s] packages could be named like dbus-python and PyQt) to build the mixer were not [ 67s] found, but BUILD_MIXER was requested. I've looked at the renamed python2-dbus-python-devel and it still provides the old dbus-1-python-devel but the modules must have been moved, I should imagine the same thing has happened to python-qt4-devel. Thanks Dave Plater -- 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] Packaging naemon: Handling systemd-related stuff in %post
by Johannes Kastl 11 May '17

11 May '17

Hi guys, I stumbled upon the naemon package in server:monitoring, and gave building naemon from the upstream spec a try: home:ojkastl_buildservice:Naemon_upstream I also tried to update the package in server:monitoring: home:ojkastl_buildservice:branches:server:monitoring I got both of them to build, but only by commenting out lots of stuff, like this: %post core case "$*" in 2) # Upgrading so try and restart if already running # For systemctl systems we need to reload the configs # becaues it'll complain if we just installed a new # init script #%if 0%{?use_systemd} # systemctl daemon-reload # systemctl condrestart %{name}.service #%else # /etc/init.d/%{name} condrestart &>/dev/null || true #%endif ;; I think (I am not an expert) upstream is trying to handle updates without having to restart the service, but this does not allow builds on OBS. My Question is if there is a 'openSUSE'-way of doing things like that? Is there any 'best practice' to do that? Any do's and dont's? (I have not thoroughly looked into the differences between the upstream spec and Lars lrupp's spec file in server:monitoring due to there being so many differences, maybe Lars already added some of this) Any hints are highly appreciated. Johannes

2 2

[opensuse-packaging] %make_jobs doesn't work
by Sascha Manns 10 May '17

10 May '17

Hello list, i have prepared that Spec [1]. But a build breaks with "%make_jobs /var/tmp/rpm-tmp.JYZHOQ: line 33: fg: no job control". See [2]. Maybe i missed a dependency? [1] https://build.opensuse.org/package/view_file/Documentation:Publican/wkhtmlt… [2] https://build.opensuse.org/package/live_build_log/Documentation:Publican/wk… Greetings Sascha -- Sascha Manns Maifeldstraße 10 56727 Mayen P: +49-2651-4014045 W: http://saigkill.tuxfamily.org -- Sascha Manns openSUSE member -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5

[opensuse-packaging] Intel MKL packaging
by auxsvr 08 May '17

08 May '17

Hi, There are several options to licence Intel MKL (free or community licence) , which makes including it in the OBS easier. If this is not allowed, what is the best way to package packages depending on it, e.g. numpy or pytorch? -- Regards, Peter -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 8

[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] gramps , gnome-introspection and spec
by doiggl＠velocitynet.com.au 05 May '17

05 May '17

Hello, # /usr/bin/gramps .gramps.gen.utils.grampslocale.WARNING: ICU not loaded because No module named 'PyICU'. Localization will be impaired. Use your package manager to install PyICU .gramps.gen.utils.grampslocale.WARNING: No valid locale settings found, using US English . You need a version which has the function 'require_version' to start Gramps # rpm -qa |grep -i gramps | sort gramps-4.2.5-77.1.noarch gramps-lang-4.2.5-77.1.noarch A question: in the build spec file, can it be altered to fix problem ? maybe a: requires ... [install 'rpm name' and minimum version number] ?? --Glenn https://build.opensuse.org/package/show/openSUSE:Factory/gramps gramps source shows: https://pythonhosted.org/Gramps/_modules/gramps/gui/grampsgui.html MIN_PYGOBJECT_VERSION = (3, 3, 2) PYGOBJ_ERR = False try: #import gnome introspection, part of pygobject import gi giversion = gi.require_version except: print(_("Your version of gi (gnome-introspection) seems to be too old. " "You need a version which has the function 'require_version' " "to start Gramps")) sys.exit(0) strace shows: # strace -e open /usr/bin/gramps open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/libpython3.4m.so.1.0", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3 open("/dev/urandom", O_RDONLY|O_CLOEXEC) = 3 open("/usr/bin/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such file or directory) open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/encodings/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/codecs.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/encodings", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/encodings/__pycache__/aliases.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/encodings/__pycache__/utf_8.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/encodings/__pycache__/latin_1.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/io.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/abc.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/_weakrefset.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/site.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/os.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/stat.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/posixpath.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/genericpath.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/_collections_abc.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/_sitebuiltins.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/sysconfig.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/_sysconfigdata.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/site-packages", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/site-packages/zzzz-import-failed-hooks.pth", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/_bootlocale.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/plat-linux", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/site-packages", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/_import_failed", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib/python3.4/site-packages", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/bin/gramps", O_RDONLY) = 3 open("/usr/bin/gramps", O_RDONLY) = 3 open("/usr/bin", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib/python3.4/site-packages/gramps/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib/python3.4/site-packages/gramps", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib/python3.4/site-packages/gramps/__pycache__/grampsapp.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/logging/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/time.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/traceback.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/linecache.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/tokenize.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/collections/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/operator.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/keyword.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/heapq.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/_heapq.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/reprlib.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/re.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/sre_compile.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/sre_parse.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/sre_constants.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/copyreg.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/token.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/warnings.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/weakref.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/string.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/threading.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/subprocess.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/_posixsubprocess.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/select.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/selectors.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/math.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib/python3.4/site-packages/gramps/gen/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib/python3.4/site-packages/gramps/gen", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib/python3.4/site-packages/gramps/gen/__pycache__/const.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/uuid.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/ctypes/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/_ctypes.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/struct.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/_struct.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/ctypes", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/ctypes/__pycache__/_endian.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/proc/mounts", O_RDONLY) = 3 open("/usr/lib64/python3.4/ctypes/__pycache__/util.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/contextlib.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/functools.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/types.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/tempfile.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/shutil.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/fnmatch.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/tarfile.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/copy.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/grp.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/bz2.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/_bz2.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/libbz2.so.1", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/random.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/__pycache__/hashlib.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/_import_failed/__pycache__/_hashlib.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/_import_failed/import_failed.map", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/_import_failed/__pycache__/_hashlib.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/_import_failed/import_failed.map", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/_md5.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/_sha1.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/_sha256.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/_sha512.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/python3.4/lib-dynload/_random.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 3 open("/dev/urandom", O_RDONLY|O_CLOEXEC) = 3 open("/dev/null", O_RDWR|O_CLOEXEC) = 4 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7140, si_status=0, si_utime=0, si_stime=0} --- open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/__pycache__/git_revision.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/__pycache__/constfunc.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/__pycache__/platform.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/__pycache__/version.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7141, si_status=127, si_utime=0, si_stime=0} --- open("/usr/lib/python3.4/site-packages/gramps/gen/utils/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/utils", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/utils/__pycache__/resourcepath.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/utils/resource-path", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/utils/__pycache__/grampslocale.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/__pycache__/gettext.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/__pycache__/locale.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 .gramps.gen.utils.grampslocale.WARNING: ICU not loaded because No module named 'PyICU'. Localization will be impaired. Use your package manager to install PyICU open("/usr/share/locale", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 .gramps.gen.utils.grampslocale.WARNING: No valid locale settings found, using US English open("/usr/lib/python3.4/site-packages/gramps/gen/__pycache__/config.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/utils/__pycache__/configmanager.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/__pycache__/configparser.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/collections", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/collections/__pycache__/abc.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7142, si_status=0, si_utime=0, si_stime=0} --- open("/usr/lib/python3.4/site-packages/gramps/gen/mime/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/mime", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/mime/__pycache__/_winmime.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/mime/__pycache__/_pythonmime.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/__pycache__/mimetypes.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/urllib/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/urllib", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/urllib/__pycache__/parse.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/etc/mime.types", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/site-packages/bsddb3/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/site-packages/bsddb3", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/site-packages/bsddb3/_pybsddb.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 4 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/libdb-4.8.so", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/site-packages/bsddb3/__pycache__/dbutils.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/site-packages/bsddb3/__pycache__/db.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/cli/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/cli", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/cli/__pycache__/argparser.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/__pycache__/getopt.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gen/utils/__pycache__/cast.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gui/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gui", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 open("/usr/lib/python3.4/site-packages/gramps/gui/__pycache__/grampsgui.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/site-packages/gi/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/__pycache__/__future__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/__pycache__/pkgutil.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/importlib/__pycache__/__init__.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/importlib", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/importlib/__pycache__/util.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/importlib/__pycache__/machinery.cpython-34.pyo", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/site-packages/gi", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 open("/usr/lib64/python3.4/site-packages/gi/_gi.cpython-34m.so", O_RDONLY|O_CLOEXEC) = 4 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/libgirepository-1.0.so.1", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/libgobject-2.0.so.0", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/libglib-2.0.so.0", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/libffi.so.4", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/libgmodule-2.0.so.0", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/libgio-2.0.so.0", O_RDONLY|O_CLOEXEC) = 4 open("/usr/lib64/libpcre.so.1", O_RDONLY|O_CLOEXEC) = 4 open("/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 4 open("/lib64/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 4 open("/lib64/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 4 Your version of gi (gnome-introspection) seems to be too old. You need a version which has the function 'require_version' to start Gramps +++ exited with 0 +++ -- 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] My first python singlespec effort
by Greg Freemyer 04 May '17

04 May '17

I maintain numerous python packages, so I thought I give one a shot at singlespec: https://build.opensuse.org/package/show/home:gregfreemyer:Tools-for-forensi… The build is failing, even for factory which should have all the needed dependencies. It says the failure is temporary, but it has been over 12 hours and I suspect the problem is with my spec file. Anyone know what I'm doing wrong? https://build.opensuse.org/package/view_file/home:gregfreemyer:Tools-for-fo… You can see in the log the python2 build works: === [ 33s] + echo python2 [ 33s] + /usr/bin/python2 setup.py build '--executable=/usr/bin/python2 -s' [ 33s] running build [ 33s] running build_py [ 33s] creating build [ 33s] creating build/lib [ 33s] creating build/lib/bencode [ 33s] copying bencode/__init__.py -> build/lib/bencode [ 33s] copying bencode/exceptions.py -> build/lib/bencode [ 33s] copying bencode/BTL.py -> build/lib/bencode [ 33s] running egg_info [ 33s] writing bencode.py.egg-info/PKG-INFO [ 33s] writing top-level names to bencode.py.egg-info/top_level.txt [ 33s] writing dependency_links to bencode.py.egg-info/dependency_links.txt === But the python3 build fails: === [ 33s] [pbr] Reusing existing SOURCES.txt [ 33s] ++ '[' -f _current_flavor ']' [ 33s] ++ cat _current_flavor [ 33s] + python_flavor=python2 [ 33s] + '[' -z python2 ']' [ 33s] + '[' python2 '!=' python3 ']' [ 33s] + '[' -d build ']' [ 33s] + mv build _build.python2 [ 33s] + '[' -d _build.python3 ']' [ 33s] + echo python3 [ 33s] + /usr/bin/python3 setup.py build '--executable=/usr/bin/python3 -s' [ 34s] Download error on https://pypi.python.org/simple/pbr/: [Errno -3] Temporary failure in name resolution -- Some packages may not be found! [ 34s] Couldn't find index page for 'pbr' (maybe misspelled?) [ 34s] Download error on https://pypi.python.org/simple/: [Errno -3] Temporary failure in name resolution -- Some packages may not be found! [ 34s] No local packages or working download links found for pbr>=1.9 [ 34s] Traceback (most recent call last): [ 34s] File "setup.py", line 13, in <module> [ 34s] pbr=True, [ 34s] File "/usr/lib64/python3.6/distutils/core.py", line 108, in setup [ 34s] _setup_distribution = dist = klass(attrs) [ 34s] File "/usr/lib/python3.6/site-packages/setuptools/dist.py", line 317, in __init__ [ 34s] self.fetch_build_eggs(attrs['setup_requires']) [ 34s] File "/usr/lib/python3.6/site-packages/setuptools/dist.py", line 372, in fetch_build_eggs [ 34s] replace_conflicting=True, [ 34s] File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 851, in resolve [ 34s] dist = best[req.key] = env.best_match(req, ws, installer) [ 34s] File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1123, in best_match [ 34s] return self.obtain(req, installer) [ 34s] File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1135, in obtain [ 34s] return installer(requirement) [ 34s] File "/usr/lib/python3.6/site-packages/setuptools/dist.py", line 440, in fetch_build_egg [ 34s] return cmd.easy_install(req) [ 34s] File "/usr/lib/python3.6/site-packages/setuptools/command/easy_install.py", line 668, in easy_install [ 34s] raise DistutilsError(msg) [ 34s] distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('pbr>=1.9') === Thanks -- Greg Freemyer -- 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] 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