openSUSE Packaging May 2017

packaging@lists.opensuse.org

33 participants
23 discussions

by Matthias Fehring

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

2 years, 8 months

singlespec python and SLE_12_SP2_Backports

by Todd Rme

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

3 years, 4 months

python singlespec: iterating over all binaries

by Sebastian

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

3 years, 6 months

Publishing disabled on KDE:Qt5 and KDE:Applications

by Mathias Homann

...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

3 years, 6 months

Noarch package, with arch-specific subpackage

by Robert Munteanu

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

3 years, 6 months

Long-failing python packages

by Todd Rme

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

3 years, 6 months

no more nobody user on OBS?

by Ruediger Meier

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

3 years, 6 months

Proposal: Update rpm configuration to fix issues and rationalize configuration

by Neal Gompa

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

3 years, 6 months

Re: [opensuse-packaging] no more nobody user on OBS?

by Ruediger Meier

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

3 years, 6 months

Re: [opensuse-packaging] no more nobody user on OBS?

by Dominique Leuenberger / DimStar

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 years, 6 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging May 2017