April 2017 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Selecting GCC version
by Matthias Fehring 03 Apr '18

03 Apr '18

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

6 13

[opensuse-packaging] singlespec python and SLE_12_SP2_Backports
by Todd Rme 05 Jul '17

05 Jul '17

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

5 7

[opensuse-packaging] Proposal: Update rpm configuration to fix issues and rationalize configuration
by Neal Gompa 24 May '17

24 May '17

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

8 29

[opensuse-packaging] Basic question on ruby packaging and build ruby-dependent packages (chef)
by Johannes Kastl 05 May '17

05 May '17

Hi all, I am currently playing with chef, and I found that packages for chef 12 are only built for Tumbleweed. This seems to be due to the required ruby version being too old on Leap and SLE. So to get a newer chef I would have to get a newer ruby on these machines. d:l:r has newer ruby packages, so my question of principle is: Can one built a newer ruby version for, say, SLES11 (or simply linkpac the one in d:l:r) and use this version during building chef12 for SLES11? I guess there would be some prjconf voodoo necessary to get it building, but will these packages be working or is this a general no-go? I found a small note on "multiple ruby version" on the openSUSE ruby packaging page advising to use rvm or docker etc., thus I am asking. Thanks in advance, Johannes P.S.: As the ruby mailinglist seems to be no longer frequented, I am asking on packaging...;-)

2 8

[opensuse-packaging] gfortran cannot link lapack and blas in obs
by Xing 02 May '17

02 May '17

Dear all, I'm packaging a program (gMultiwfn) which uses lapack and blas. It can compile without any problem by using './configure && make install' directly. However when I was packaging it on OBS, the lapcak and blas cannot be found by gfortran and the error is: [ 57s] gfortran -O3 -std=legacy -fopenmp -llapack -lblas -o Multiwfn Multiwfn-Lebedev-Laikov.o Multiwfn-DFTxclib.o Multiwfn-define.o Multiwfn-util.o Multiwfn-function.o Multiwfn-sub.o Multiwfn-fileIO.o Multiwfn-spectrum.o Multiwfn-DOS.o Multiwfn-wfn.o Multiwfn-population.o Multiwfn-compana.o Multiwfn-bondana.o Multiwfn-topology.o Multiwfn-excittransana.o Multiwfn-otherfunc.o Multiwfn-otherfunc2.o Multiwfn-surfana.o Multiwfn-procgriddata.o Multiwfn-AdNDP.o Multiwfn-fuzzyana.o Multiwfn-CDA.o Multiwfn-basinana.o Multiwfn-atmraddens.o [ 57s] Multiwfn-util.o: In function `__util_MOD_diaggemat': [ 57s] util.f90:(.text+0x36a7): undefined reference to `dgeev_' [ 57s] Multiwfn-util.o: In function `__util_MOD_diagsymat': [ 57s] util.f90:(.text+0x3a42): undefined reference to `dsyev_' [ 57s] collect2: error: ld returned 1 exit status [ 57s] Makefile:392: recipe for target 'Multiwfn' failed [ 57s] make[1]: *** [Multiwfn] Error 1 [ 57s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/gMultiwfn-3.3.9-0/build/src' [ 57s] Makefile:356: recipe for target 'all-recursive' failed [ 57s] make: *** [all-recursive] Error 1 [ 57s] error: Bad exit status from /var/tmp/rpm-tmp.bHBPuv (%build) where dgeev_ and dsyev_ are the functions in lapack. Multiwfn-*.o are the obj files just compiled by gfortran. I did require lapack-devel and blas-devel and the -llapack and -lblas options were checked by the configure script (using gcc I think) (Installaton of libblas and liblapack:) [ 14s] [66/107] cumulate libblas3-3.5.0-8.2 ... [ 14s] [68/107] cumulate blas-devel-3.5.0-8.2 ... [ 14s] [84/107] cumulate lapack-devel-3.5.0-8.2 ... [ 14s] [84/107] cumulate lapack-devel-3.5.0-8.2 (checking -lblas and -llapack using gcc): [ 30s] checking for Fortran 77 libraries of gfortran... -L/usr/lib64/gcc/x86_64-suse-linux/4.8 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../.. -lgfortran -lm -lquadmath [ 30s] checking for gcc... gcc [ 30s] checking whether we are using the GNU C compiler... yes [ 30s] checking whether gcc accepts -g... yes [ 30s] checking for gcc option to accept ISO C89... none needed [ 30s] checking whether gcc understands -c and -o together... yes [ 30s] checking for dummy main to link with Fortran 77 libraries... none [ 30s] checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore [ 31s] checking if sgemm_ is being linked in already... no [ 31s] checking for sgemm_ in -lopenblas... no [ 31s] checking for ATL_xerbla in -latlas... no [ 31s] checking for sgemm_ in -lblas... yes [ 31s] checking for dgemm_ in -ldgemm... no [ 31s] checking for sgemm_ in -lmkl_gf_lp64... no [ 31s] checking for sgemm_ in -lmkl... no [ 31s] checking for sgemm_ in -framework vecLib... no [ 31s] checking for sgemm_ in -lcxml... no [ 31s] checking for sgemm_ in -ldxml... no [ 31s] checking for sgemm_ in -lscs... no [ 31s] checking for sgemm_ in -lcomplib.sgimath... no [ 31s] checking for sgemm_ in -lblas... (cached) yes [ 31s] checking for sgemm_ in -lessl... no [ 31s] checking for sgemm_ in -lblas... (cached) yes [ 32s] checking for cheev_... no [ 32s] checking for cheev_ in -llapack... yes [ 32s] checking for a BSD-compatible install... /usr/bin/install -c [ 32s] checking whether build environment is sane... yes [ 32s] checking for a thread-safe mkdir -p... /usr/bin/mkdir -p [ 32s] checking for gawk... gawk [ 32s] checking whether make sets $(MAKE)... yes [ 32s] checking for style of include used by make... GNU [ 32s] checking whether make supports nested variables... yes [ 32s] checking dependency style of gcc... none Really confusing for me...Is there any special caution to use gfortran in OBS? Thanks and best wishes, Xing -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] Non-blocking %check
by Todd Rme 01 May '17

01 May '17

There has been some work and advice recently about improving the parallelization of project builds. However, one issue that occurred to me is that a lot of time can be spent running the %check scriptlet that shouldn't have any impact on the final RPMs. My idea was that perhaps the RPM could be used for building packages that depend on it while the %check scriptlet is running. If the %check succeeds, then everything continues as normal. If not, then builds that depend on it are canceled and RPMs that depend on it are invalidated before being published. I understand that this is a big change. In addition to needed big changes in how OSC works, this would also require a fundamental change in the %check macro. It would mean that things that happen during the %check scriptlet would no longer have any impact on the final RPMs. Personally I think this is a feature rather than a bug, I always thought it was strange that tests are allowed to change the package, but it is a big behavior change. I am not sure this is worth the effort to implement or worth breaking existing RPM semantics. But if we are having a problem with the builds not being as parallel as they could be, this might be something at least to consider. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 13

[opensuse-packaging] Requires(pre): user(wwwrun)
by Johannes Weberhofer 26 Apr '17

26 Apr '17

Dear all! When I understand it right, for future builds it is necessary to include systemusers like wwwrun when required. This currently is supported only on Tumbleweed and breaks building on other systems. How can we handle that? Especially if Leap is going back to a 15 version? Please help! -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 5

[opensuse-packaging] Package deletion notice: python-mvpa
by Todd Rme 24 Apr '17

24 Apr '17

python-mvpa no longer builds for any openSUSE release, due to an apparent incompatibility with recent versions of numpy. It seems this package is unmaintained because it was replaced with python-pymvpa2. However, python-pymvpa2 has a different module name (pyvmpa2 vs. pyvmpa) so it will not work with packages that require python-mvpa. I will submit python-pymvpa2 shortly. However, if anyone has any need for python-mvpa (the old version), please fix it. If I haven't received a fix or at least heard anyone commit to doing a fix (and maintaining it longer-term) I will delete the package in one week (on Monday, May 1). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] release-notes-openSUSE requires google-opensans-fonts
by Felix Miata 23 Apr '17

23 Apr '17

TW $SUBJECT can't be right, but trying to zypper rm opensans wants to remove releasenotes. :-( -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 8

[opensuse-packaging] Distinguishing architectures in spec file leads to failed requirements for required packages that are available
by Thomas Wagner 20 Apr '17

20 Apr '17

Hi! Building encfs requires tinyxml2-3, which is part of Leap 42.2 Tumbleweed but not available for all architectures. There is currently the following condition in the spec file: ... %if 0%{?sle_version}>=120200 || 0%{?suse_version} > 1320 %define os_has_tinyxml2 1 %else %define os_has_tinyxml2 0 %endif ... %if %{os_has_tinyxml2} BuildRequires: tinyxml2-devel %endif ... I changed the condition to a more specific one which contains the corresponding architectures: %if ( 0%{?leap_version}>=420200 && %{_arch} == x86_64 ) || ( 0%{?suse_version} > 1320 && %{_arch} != ppc ) My new condition works and os_has_tinyxml2 is set correctly (output of condition remains the same for unaffected architectures), but later on, I get errors "tinyxml2-devel is needed" for those architectures that definitely have tinyxml2-devel, e.g. all Factory other than ppc and Leap 42.2 x86_64. Why does changing the condition result in a failed requirement, even if the output of the condition is the same? best regards Thomas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] wkhtmltopdf-qt: Build breaks on Tumbleweed
by Sascha Manns 20 Apr '17

20 Apr '17

Hello List, i prepared a package of qt for wkhtmltopdf on [1]. It builds on Leap 42.2, but not on Tumbleweed. Maybe anyone has an idea, how to get this working? The Tumbleweed Buildlog is placed there [2]. [1] https://build.opensuse.org/package/show/Documentation:Publican/wkhtmltopdf-… [2] https://build.opensuse.org/build/Documentation:Publican/openSUSE_Tumbleweed… Greetings Sascha -- Sascha Manns openSUSE member -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] How define a signing key for a project
by Dieter Bloms 19 Apr '17

19 Apr '17

Hello, we are running an own private obs appliance. I've a gpg key and want to use this for all my project. I've added my gpg key in the keyring of /srv/obs/gnupg and defined it in /etc/sign.conf. The rpms were signed by my gpg key, but my gpg key is not used to sign the repos of my projects. The repos were signed with the key of "defaultkey@localobs". I read the online obs reference guide http://openbuildservice.org/help/manuals/obs-reference-guide/cha.obs.signin… but there is only an empty chapter "Configure sign key" Can anybody tell me how to define the project signing key ? Thank you very much. -- Regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] devel:language:python Factory/Tumbleweed build target changes
by Todd Rme 17 Apr '17

17 Apr '17

I have just implemented some changes for the various factory targets of devel:languages:python. Most importantly, the openSUSE_Factory_ARM, openSUSE_Factory_PowerPC, and openSUSE_Factory_zSystems build targets have been rolled into the openSUSE_Tumbleweed build target. They are now architectures of openSUSE_Tumbleweed rather than stand-alone repositories. The existing repositories are still there. Assuming there are no problems they will be disabled on in 2 days (Sunday, April 2) and will be deleted in one week (Friday, April 7 2017). Second, the opensuse_factory_staging build target has already been deleted. It was purely a testing repository, so nobody should have been using it to begin with. Thank you, Todd -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] Some more python singlespec questions/suggestions
by Todd Rme 14 Apr '17

14 Apr '17

A few questions and ideas have popped up for me while doing the singlespec conversion: First, is there a way to use the macros without actually setting up the multiple packages? Particularly I need to use %{python_module foo}, but %python_expand and %python_exec would also be useful. The main use-case is for packages where the unit tests have been moved into a separate -doc spec file to avoid dependency cycles. These packages need to import both python2 and python3 dependencies to for the unit tests, and ideally would use %python_expand or %python_exec to run the tests. But the documentation itself would only be built once, so we don't need multiple rpms. I tried %_python_macro_init but it didn't work. Second, is there a single-spec version of %py(3)_compile? Ideally it would be nice to have %python2_compile and %python3_compile that could be used with %python_expand, as well as a macro that automatically run them both on %{buildroot}%{python(2/3)_sitelib} and %{buildroot}%{python(2/3)_sitearch} (whichever exists). Third, is there a macros to get just the current python major version number? So "2" for python2 and "3" for python3? So projects, such as the jupyter suite, use a "foo2-bar"/"foo3-bar" pattern that we need to support, so having a macro to get the major number is pretty critical especially since IPython is dropping python2 support soon so we need to be able to adjust the build targets easily. Third, the wiki recommends defining %oldpython when you need a specific python-foo dependency. Considering how often the backports are used these days in python2 packages, might this be a macro that would be good to include so people don't have to manually define it? Fourth, I notice the python2-foo versions of the packages (for Tumbleweed) provide python-foo, but the python-foo versions (for older releases) do not provide python2-foo. For maximum simplicity and compatibility, might it be good to have the python-foo versions also provide python2-foo? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 4

[opensuse-packaging] A new home for python3 packages
by Luigi Baldoni 14 Apr '17

14 Apr '17

Hi, I've noticed that some python3 packages I need are, in fact, python3-only and that some other cannot be unified at the moment, if ever. Also with the expectation of a mass-conversion d:l:p3 has been a tad neglected lately, so I was wondering if the packages above could be rehomed to d:l:p. Or perhaps it's too early? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/A-new-home-for-python3-packages-tp5084623.… Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 11

[opensuse-packaging] %license is no longer working?
by Sebastian 12 Apr '17

12 Apr '17

Dear list, I wanted to port a python3 package to the singlespec approach and I was stuck with a strange behavior of %license, which is only available on >= 42.2. I therefore use this condition: %if 0%{?leap_version} >= 420200 || 0%{?suse_version} > 1320 %license LICENSE %else %doc LICENSE %endif Which works fine, e.g. here: https://build.opensuse.org/package/show/network:utilities/macchanger But not for this package: https://build.opensuse.org/package/show/home:sebix:branches:devel:languages… Error message is, for 42.2 and TW: [ 40s] RPM build errors: [ 40s] File must begin with "/": MIT [ 40s] File must begin with "/": LICENSE Apparently %license is replaced by the value of the "License:" field. Does anyone have a clue why this is not working now? Sebastian -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers

1 0

[opensuse-packaging] python singlespec and quilt
by Hans-Peter Jansen 12 Apr '17

12 Apr '17

Hi, there's another unsolved issue lurking around the corner: quilt stumbles across the singlespec format for the time being. Is somebody working on a solution already? Cheers, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] package is built from outdated sources
by Rüdiger Meier 10 Apr '17

10 Apr '17

Hi, my packages home:rudi_m/dateutils and utilities/dateutils are currently identical. But in utilities/ it is somewhow build from other sources, see the logs. For example it does not apply the patch 0001-fix-when-printing-zones-transitioning-at-INT_MAX-in-.patch What's going on here? cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] fixes for rpmlint ? python singlespec pyc, opt-1.pyc
by Bruno Friedmann 07 Apr '17

07 Apr '17

For any packages build with the new singlespec way there those warnings [ 21s] RPMLINT report: [ 21s] =============== [ 21s] python3-mappyfile.noarch: W: files-duplicate /usr/lib/python3.6/site- packages/mappyfile/__pycache__/tokens.cpython-36.pyc /usr/lib/python3.6/site- packages/mappyfile/__pycache__/tokens.cpython-36.opt-1.pyc [ 21s] python3-mappyfile.noarch: W: files-duplicate /usr/lib/python3.6/site- packages/mappyfile/__pycache__/__init__.cpython-36.opt-1.pyc /usr/lib/ python3.6/site-packages/mappyfile/__pycache__/__init__.cpython-36.pyc [ 21s] python3-mappyfile.noarch: W: files-duplicate /usr/lib/python3.6/site- packages/mappyfile-0.2.0-py3.6.egg-info/not-zip-safe /usr/lib/python3.6/site- packages/mappyfile-0.2.0-py3.6.egg-info/dependency_links.txt [ 21s] python3-mappyfile.noarch: W: files-duplicate /usr/lib/python3.6/site- packages/mappyfile/__pycache__/ordereddict.cpython-36.opt-1.pyc /usr/lib/ python3.6/site-packages/mappyfile/__pycache__/ordereddict.cpython-36.pyc [ 21s] 3 packages and 0 specfiles checked; 0 errors, 4 warnings. Should RPMLINT be fixed to become smarter, and just ignore those, or something still need to be fixed in the python part ? -- 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 6

[opensuse-packaging] Do we use %{!?_docdir_fmt:-%{version}
by Sascha Manns 04 Apr '17

04 Apr '17

Hello list, currently i'm packaging a app, where upstream (Fedora) uses: %{_docdir}/%{name}-doc%{!?_docdir_fmt:-%{version}} Do we use that? Or must i use it in another way? Greetings Sascha -- Sascha Manns openSUSE member -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Package publishing: per target or per arch?
by Todd Rme 03 Apr '17

03 Apr '17

I am a bit unclear about the rules for when build packages are pushed to repositories. I have been told that it only occurs for a given build target when all architectures for that target have finished building. However, when I look at download.opensuse.org, it seems packages are getting pushed from one architecture while another is still building according to build.opensuse.org. So I was hoping to get a better understanding of how OSC decides whether to publish a package. It is important because it has an impact on how we structure our build targets. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2