Hello!
I'm trying to build python-pytest-relaxed for SLE-12 in backports which
is required as a dependency for one of the tools we are using for the
public cloud stuff.
The build fails with RPM complaining about /usr/share/licenses being unowned:
[ 4s] ... running 01-check-debuginfo
[ 4s] ... testing for empty debuginfo packages
[ 4s] ... running 02-check-gcc-output
[ 4s] ... testing for serious compiler warnings
[ 4s] (using /usr/lib/build/checks-data/check_gcc_output)
[ 4s] (using /var/tmp/build-root/openSUSE_Backports_SLE-12-x86_64/.build.log)
[ 4s] ... running 03-check-binary-kernel-log
[ 4s] ... running 04-check-filelist
[ 4s] ... checking filelist
[ 4s] python-pytest-relaxed-1.0.0-0.noarch.rpm: directories not owned by a package:
[ 4s] - /usr/share/licenses
[ 4s] python3-pytest-relaxed-1.0.0-0.noarch.rpm: directories not owned by a package:
[ 4s] - /usr/share/licenses
[ 4s]
[ 4s] suse-laptop failed "build python-pytest-relaxed.spec" at Fri Dec 15 13:35:27 UTC 2017.
[ 4s]
Normally, this issue is fixed by installing the package which install this directory
into the chroot, either through a Preinstall directive in the project configuration
or by adding the package in question to Build-Depends in the spec file.
The directory /usr/share/licenses is provided by filesystem which I tried preinstalling
through the aforementioned mechanisms. However, I still keep running into the ownership
issue as shown above.
Does anyone have any idea what I am doing wrong?
Thanks,
Adrian
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
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
Hi!
I have a quick question regarding extra documentation files.
The upstream tarball of python-msrestazure is missing a separate
LICENSE file. I just downloaded the one from the github repository
and added it with "Source1: LICENSE.md" in the spec file.
However, adding it to the %doc section doesn't work, during package
build, the file isn't found because it apparently needs to be copied
into the source root first.
Is there any common way to place additional text files into %doc?
Adrian
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Script 'mail_helper' called by idoenmez
Hi opensuse-packaging(a)opensuse.org,
/mounts/work_src_done/SLE12-SP3-CASP30-STAGING/yarn was not checked in by idoenmez for the following reasons:
(submitrequest 152745 on https://build.suse.de)
Please submit to Factory first.
your dist/autobuild team.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I've seen a previously working package now failing, and I don't understand why
it would be failing now.
https://build.opensuse.org/package/live_build_log/
home:bruno_friedmann:branches:Application:Geo/qgis-master/openSUSE_Tumbleweed/
x86_64
Any hint ?
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
Bareos Partner, openSUSE Member, fsfe fellowship
GPG KEY : D5C9B751C4653227
irc: tigerfoot
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi I've had build failures specifically on 42.3 packages that need gcc5
and up to build. The failures are due to -fstack-clash-protection,
which only works with gcc7, having been added to %optflags. Strangely
42.2 builds with gcc5 don't have this flag.
Is there any way to bypass this besides rewriting %optflags?
Why is this flag in 42.3 builds but not 42.2?
Why does this flag pass on gcc48?
Thanks
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
Some time ago I had to make some changes to the LLVM package. It caused some
issues and took some time to stabilize, but I thought it is done and working
correctly now. Unfortunatelly, it turned out it is still broken and more
changes are needed. Before I start breaking things again, I would like to
describe here what happened and what I think still needs to happen.
The LLVM package builds several related projects: llvm, clang, libcxx, lldb,
lld, and other small ones. These projects can be either placed into a single
source tree and built all together, or they can be built individually. From
packaging point of view, it would be cleaner if we built them separately, but
since we need to bootstrap clang and then use it to build itself, we have to
build at least llvm, clang and libcxx together. So it is easier to just build
them all together.
Each of the projects is divided into components (such as LLVM/Analysis, LLVM/
AsmParser, clang/AST, clang/CodeGen, ...).
LLVM can be built in different modes:
1) Every component will compile into a shared library.
2) Every component will compile into a static library.
3) Every project will compile into a single shared library containing all its
components.
Before I started working on the package, we were building LLVM using mode 1.
This caused us some troubles, all that I am aware of are listed in this bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=1049703
When trying to fix these issues with upstream, we were told that this build
mode is only meant for the llvm developers and the issues would not happen if
we used one of the recommended modes (2 or 3).
https://github.com/klee/klee/pull/686
> Maybe openSUSE have a good reason for doing this but going against a
> project's recommended practice seems like a bad idea.
> You can file a bug on LLVM.org to investigate fixing that, however it is
> unlikely that much attention will be given to the BUILD_SHARED_LIBS build
> because it is strongly discouraged.
The same information is also stated in the LLVM build documentation. So I went
ahead and changed LLVM package to the mode 3 (single shared library for every
project). Unfortunatelly the clang project does not support this mode. So the
clang components are instead built as static libraries and distributed in the
new clang-devel-static package.
This is the current state of the package. One drawback is that the llvm
package now takes longer to build and consumes more resources in OBS. (Linking
stuff together into big libraries takes longer and the static libraries cause
increase file size. Biggest slow down is in extracting debuginfo and
compressing the RPM files.) That caused the LLVM package to be a bottleneck in
the distribution build and needed to be solved (bnc#1064786). I spent lot of
time trying to optimize the build and also had to split Mesa to a llvm and
non-llvm part (bnc#1071297) to reduce the amount of packages that transitively
depend on llvm. The situation is now better, although still not that good.
Recently a new bug got to me:
https://bugzilla.opensuse.org/show_bug.cgi?id=1065464
That bug shows that OpenCL is broken if you have multiple OpenCL
implementations which use clang installed at once. Note that it is perfectly
ok to have them installed at once. Applications are supposed to load them all,
query them and pick one to use. However, when a program loads two libraries
statically linked with the clang libraries, it aborts. The reason is that each
of them try to register a configuration option into the llvm library - but
there is only one shared llvm library used by both of them. It aborts during
the second attempt to register the same configuration option. There is a
request upstream to change the way llvm handles configuration options, but it
is a big task and not likely to be done any time soon.
So it can only work if both clang and llvm are static or both shared
libraries. I am against making them all static. In addition to all the good
reasons why we try to stay away from static libraries, it would likely make
the llvm build times even worse.
Instead, I would like to try approach similar to what Fedora does - they build
all of llvm using the mode 3 (each project as single shared library), except
for clang which they build with mode 1 ("developer" mode where every component
ends up as a shared library). Fedora has easier time doing that because they
have them in separate packages, but we can do it too using a small patch to
the llvm build system (tested).
This should:
* Fix the OpenCL bug.
* Get rid of static libraries and the clang-devel-static package.
* Reduce llvm build time.
* Maybe reintroduce some bugs since we will be partially using the unsupported
"developer" mode again. But it would be only for clang, llvm and all the
other components would still use the supported mode. AFAIK all the bugs I
know of were caused by the llvm libraries. I will test for regressions
before submitting anything.
Comments and suggestions are welcome.
Michal Srb
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
I've just created a virgin Leap 42.3 VM.
I want to test out request_tracker from devel:languages:perl. I've
added the repo, but when it fails in the %pre section of "zypper in
request_tracker".
The spec file has these 3 lines in the %pre section:
# enable needed services
%fillup_and_insserv -f apache2
%fillup_and_insserv -f mysql
%fillup_and_insserv -f postfix
It errors out with:
Error: Subprocess failed. Error: RPM failed: /var/tmp/rpm-tmp.LhHfVl:
line 23: /etc/init.d/apache2: No such file or directory
It's correct that doesn't exist because 42.3 is systemd based (I
assume that's the reason).
%fillup_and_insserv is a common macro which surely should work fine in
a 42.3 machine.
What in the world is going on?
Greg
--
Greg Freemyer
Advances are made by answering questions. Discoveries are made by
questioning answers.
— Bernard Haisch
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
* Bug 1075901 - [Mesa 17.3.2] Some OpenGL applications cause system to freeze
- Newest generation of AMD GPU that just became supported in llvm5
- It is not regression in either Mesa or llvm
- Similar looking upstream bug turned out to be unrelated
- Investigating VM fault report - nothing obviously wrong in the active
shader, but texture sampler reportedly corrupted in GPU memory
- That could cause fault when running this shader, not clear what
corrupted it.
- Going to test with newer/patched llvm
* Bug 1075403 - L3: VNC connection fails from windows browser when 16bit color
is set.
- Fix confirmed working, submitted it everywhere.
* Bug 1071297 - split up Mesa to speed up distribution build
- Silenced last repo-checker complaint. It's done, bug closed.
* Bug 1065464 - Don't allow multiple OpenCL ICD packages to be installed
simultaneously
- Big NO to making packages providing OpenCL ICDs conflict with each other
(the purpose of ICDs is to allow multiple implementations to co-exist on
one system!)
- Big NO to building all llvm libraries as static
- However, the issue is real. After investigating it looks like to way llvm
package is build must be changed some more.
- Did some initial tests.
- Described my plan on opensuse-packaging(a)opensuse.org
* Mesa packaging
- Updated to version 17.3.3
- Simple backport to add Coffee lake GPU support (requested by Intel)
* LLVM packaging
- dropped version 3.8 from factory, 4 and 5 remain
Michal
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
I am really stuck with %gobuild usage.
Here
https://build.opensuse.org/package/view_file/server:database/influxdb/influ…
I need to pass the following to the linker
-ldflags="-X main.version=1.2.3"
and I am trying to use
%gobuild -ldflags="-X main.version=1.2.3" cmd/...
as it supposed to work, but it doesn't.
--
With best regards,
Matwey V. Kornilov
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org