openSUSE Packaging June 2017

packaging@lists.opensuse.org

38 participants
23 discussions

[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

3 years, 2 months

[opensuse-packaging] How to "Provide" <name> for python singlespec packages without the "python2/3"-prefix?

by Oliver Kurz

With python singlespec my package names get prepended by python3- or python2- in all cases. Can I somehow achieve to provide a package name for one of the two python versions without any "python2/3-" prefix? For example: https://build.opensuse.org/package/view_file/network:messaging:matrix/matri… has Name: matrix-synapse but is a full python singlespec spec file yielding * python2-matrix-synapse * python3-matrix-synapse but I would like at least one package to be or "provide" matrix-synapse. If not possible I would also be ok to build it just with one python version to end up with just "matrix-synapse". But again: What's the proper way? Regards, Oliver -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 11 months

[opensuse-packaging] 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, 11 months

[opensuse-packaging] Factory submission policy in light of default-python switch

by jan matejek

fellow pythonistas, i'd like to propose a new review rule: do not accept new python modules into Factory that are not either singlespec or explicitly versioned. So "python2-foo" is fine, "python3-foo" is fine, "python-foo" which is not singlespec is rejected. For apps that have python as a requirement, do not accept anything that requires "python", and look hard on apps that require "python2". (they should require python3 unless the app actually doesn't work with it) This would apply to *new* packages. Anyone opposed? I'd like to apply to existing packages too... as in, if you touch a thing that requires python, also make sure that it is versioned. But perhaps this is not a reason for rejection, more like, leave a comment "can you please also do this"? Thoughts? m.

3 years, 11 months

[opensuse-packaging] singlespec RFC: python3-only builds, %have_python, %skip_python

by jan matejek

Fellow Python packagers, while trying to solve the issues surrounding python3-only singlespec builds, I finally figured out that the OBS is not *at all* doing what I thought it was doing, and everything is now lost forever and now seriously. For various technical reasons that I will discuss at the end of this e-mail, using "%undefine have_python2" for removing python2 from the build set is not viable. I will have to redesign the macros that are present in prjconf and use some other method to accomplish the same. The current WIP solution is as follows: 1. %pythons macro will contain the build set, i.e., list of all flavors that we build for. in Factory, "%pythons" will expand to "python2 python3". 2. contents of %pythons will be conditional on %skip_python macros. If you "%define skip_python2 1" in the spec file, python2 will be removed from %pythons. the "%skip_python" symbols should not be defined ANYWHERE ELSE BUT the current spec file. For prjconf, it is more suitable to change contents of %pythons. 3. %python_module will iterate over %pythons, through a crazy convoluted scheme that Ruby is also using. So for the end packager: * if you want to build everything by distro defaults, nothing changes * if you want to *exclude* a particular flavor from the build, you "%define skip_$flavor 1" * if you want to list build flavors explicitly, you can redefine %pythons themselves: %define pythons python2 jython2 pypy3 * you can BuildRequire: %pythons, because %pythons will come from prjconf For prjconf, we need: * %pythons python2 python3 (This is an opportunity to mess things up, because the *last* item in %pythons actually specifies, through a side effect, the "default" python that overwrites conflicting files. If you specify "python3 python2" and then "%python3_only /usr/bin/foo", the /usr/bin/foo will actually be a python2 version. OTOH, this allows per-package customization of the default, and python-rpm-macros will contain the canonical order.) * the set of python_module expanders Installed Python packages will still define %have_$flavor macros, so you can switch build options based on which pythons are present. However, this is no longer tied to the build set: especially in a local build, you could get %have_python2 true but not actually build it for Python2. That shouldn't matter in practice. comments, questions, thoughts? regards m. ----- p.s.: For those interested, here are the technical details. The original intention was that if you wanted to skip a particular build requirement, you could do: %undefine have_python2 This would remove "python2" from the build set and you wouldn't get any python2-related wording in the spec file. One problem with this approach is that definitions in RPM are placed on a stack and so you need to %undefine as many times as you %defined. Hence the current bug where you need to %undefine have_python2 twice (at least). Another is that OBS doesn't understand %undefine at all! So this declaration actually doesn't do anything, and your %python_modules still install *all* python versions. The double-%undefine is then needed because you get one have_python2 from prjconf and another from the installed python2 package. The new solution doesn't rely on undefines, and redefinitions work about as well as we would expect.

3 years, 11 months

[opensuse-packaging] Source service validation on github source service

by Axel Braun

Hi, maybe someone can give me a hand... I submitted projectlibre to Factory, after having implemented a source service to pull from github: https://build.opensuse.org/request/show/500851 This got rejected by the source service validator, as the project does not provide the tarball as such for download. Pointing to github seems not to be a valid idea either, as the source service has some steps to take Any idea how to overcome this situation? Thanks Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 12 months

[opensuse-packaging] fpc for 42.2 question

by Mikhail Terekhov

Hi, How to fix "unresolvable" state for the fpc package on 42.2: https://build.opensuse.org/package/show/devel:languages:pascal/fpc Could adding 42.1 repository for build on 42.2 fix the problem? Regards, Mikhail -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 12 months

[opensuse-packaging] haskell: armv7hl

by Matwey V. Kornilov

Hello, How could I help in bringing haskell packages to armv7l architecture? Now Factory lacks all haskell packages for this arch. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 12 months

[opensuse-packaging] Gcc7 or QT59 bug ?

by Bruno Friedmann

Build qgis-master (the future 3.0 version) based on qt5 give me an error now on TW since 3-4 days. [ 4316s] [ 88%] Linking CXX executable ../../../output/bin/qgis_ogcutilstest [ 4316s] cd /home/abuild/rpmbuild/BUILD/qgis- master-0+git1497708569.c69c5963d0/build/tests/src/core && /usr/bin/cmake -E cmake_link_script CMakeFiles/qgis_ogcutilstest.dir/link.txt --verbose=1 [ 4316s] /usr/bin/c++ -fmessage-length=0 -grecord-gcc-switches -O2 -Wall - D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous- unwind-tables -g -DNDEBUG -DSPATIALITE_VERSION_GE_4_0_0 - DSPATIALITE_VERSION_G_4_1_1 -DSPATIALITE_HAS_INIT_EX -Wall -Wextra -Wno-long- long -Wformat-security -Wno-strict-aliasing -O3 -DNDEBUG -Wl,--as-needed - Wl,--no-undefined -Wl,-z,now -Wl,--no-undefined -rdynamic CMakeFiles/ qgis_ogcutilstest.dir/testqgsogcutils.cpp.o CMakeFiles/qgis_ogcutilstest.dir/ qgis_ogcutilstest_autogen/moc_compilation.cpp.o -o ../../../output/bin/ qgis_ogcutilstest -L/home/abuild/rpmbuild/BUILD/qgis- master-0+git1497708569.c69c5963d0/build/src/core -L/home/abuild/rpmbuild/ BUILD/qgis-master-0+git1497708569.c69c5963d0/build/src/gui -Wl,-rpath,/home/ abuild/rpmbuild/BUILD/qgis-master-0+git1497708569.c69c5963d0/build/src/core:/ home/abuild/rpmbuild/BUILD/qgis-master-0+git1497708569.c69c5963d0/build/src/ gui:/home/abuild/rpmbuild/BUILD/qgis-master-0+git1497708569.c69c5963d0/build/ output/usr/lib64 /usr/lib64/libQt5Test.so.5.9.0 -lproj -lgeos_c -lgdal ../../../output/usr/lib64/libqgis_core.so.2.99.0 /usr/lib64/libQt5Xml.so.5.9.0 /usr/lib64/libQt5Concurrent.so.5.9.0 /usr/lib64/libQt5PrintSupport.so.5.9.0 / usr/lib64/libQt5Svg.so.5.9.0 /usr/lib64/libQt5WebKitWidgets.so.5.9.0 /usr/ lib64/libQt5Widgets.so.5.9.0 /usr/lib64/libQt5WebKit.so.5.9.0 /usr/lib64/ libQt5Gui.so.5.9.0 /usr/lib64/libQt5Network.so.5.9.0 /usr/lib64/libQt5Sql.so. 5.9.0 -lqca-qt5 -lqtkeychain -lproj -lgeos_c -lgdal -lspatialindex -lexpat - lsqlite3 -lspatialite /usr/lib64/libQt5Positioning.so.5.9.0 /usr/lib64/ libQt5Core.so.5.9.0 [ 4316s] CMakeFiles/qgis_ogcutilstest.dir/testqgsogcutils.cpp.o: In function `std::__atomic_base<int>::store(int, std::memory_order)': [ 4316s] /usr/include/c++/7/bits/atomic_base.h:374: undefined reference to `qt_qhash_seed' [ 4316s] /usr/include/c++/7/bits/atomic_base.h:374: undefined reference to `qt_qhash_seed' [ 4316s] collect2: error: ld returned 1 exit status [ 4316s] make[2]: *** [tests/src/core/CMakeFiles/qgis_ogcutilstest.dir/ build.make:150: output/bin/qgis_ogcutilstest] Error 1 [ 4316s] make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/qgis- master-0+git1497708569.c69c5963d0/build' [ 4316s] make[1]: *** [CMakeFiles/Makefile2:10140: tests/src/core/CMakeFiles/ qgis_ogcutilstest.dir/all] Error 2 [ 4316s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/qgis- master-0+git1497708569.c69c5963d0/build' [ 4316s] make: *** [Makefile:166: all] Error 2 I've seen two updates of gcc7 during the week, and of course the qt59 introduction, is it linked to ? Known bug already ? Building project is located here https://build.opensuse.org/package/show/ home:bruno_friedmann:branches:Application:Geo/qgis-master -- 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

4 years

[opensuse-packaging] usermod: group 'uucp' does not exist

by Matwey V. Kornilov

Hello, I am currently see the following error on Tumbleweed: [ 106s] ... running 06-check-installtest [ 106s] ... testing for pre/postinstall scripts that are not idempotent [ 107s] usermod: group 'uucp' does not exist Where did the groups go? I also see the following: [ 72s] ... running 06-check-installtest [ 72s] ... testing for pre/postinstall scripts that are not idempotent [ 73s] usermod: group 'video' does not exist But group 'video' is referenced in 50-udev-default.rules -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging June 2017