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