openSUSE Packaging January 2018

packaging@lists.opensuse.org

37 participants
27 discussions

[opensuse-packaging] Ownership issues with /usr/share/licenses in SLE-12

by John Paul Adrian Glaubitz

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

2 years, 10 months

[opensuse-packaging] Selecting GCC version

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, 10 months

[opensuse-packaging] Installing extra text files into doc directory fails

by John Paul Adrian Glaubitz

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

3 years

[opensuse-packaging] /mounts/work_src_done/SLE12-SP3-CASP30-STAGING/yarn not checked in

by idoenmez

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

3 years

[opensuse-packaging] Strangely debugbuild info

by Bruno Friedmann

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

3 years, 1 month

[opensuse-packaging] Why has -fstack-clash-protection been added to optflags?

by Dave Plater

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

3 years, 1 month

[opensuse-packaging] LLVM package changes

by Michal Srb

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

3 years, 1 month

[opensuse-packaging] %fillup_and_insserv not working during zypper install ?? Leap 42.3

by Greg Freemyer

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

3 years, 1 month

[opensuse-packaging] Work report - msrb - week 3

by Michal Srb

* 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

3 years, 1 month

[opensuse-packaging] Fwd: openSUSE: golang packaging

by Matwey V. Kornilov

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

3 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging January 2018