openSUSE Packaging August 2017

packaging@lists.opensuse.org

34 participants
29 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

2 years, 8 months

Re: [opensuse-packaging] New packaging guidelines for PHP7 pacakges

by Andrew Daugherity

> On Aug 31, 2017, at 2:07 PM, Johannes Weberhofer <jweberhofer(a)weberhofer.at> wrote: > > Am 30.08.17 um 22:01 schrieb Christian Boltz: >> This should probably be <= 1320 (unless you want to exclude 13.2, which >> sounds unlikely) >> Besides that, your proposal looks good:-) > > Thanks for you response! > > Leap seems to be 1330 at the moment; I'll update this. Not in 42.x. Looks like Tumbleweed is currently 1330 (according to https://en.opensuse.org/openSUSE:Packaging_for_Leap#RPM_Distro_Version_Macr…, but footnoted as "never rely on this version, it may change"). $ rpm --eval %suse_version 1315 $ grep '^%.*_version' /usr/lib/rpm/suse_macros %suse_version 1315 %sles_version 0 %ul_version 0 %leap_version 420300 %sle_version 120300 $ cat /etc/os-release NAME="openSUSE Leap" VERSION="42.3" ID=opensuse ID_LIKE="suse" VERSION_ID="42.3" PRETTY_NAME="openSUSE Leap 42.3" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:leap:42.3" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/“ Thanks for your work; hope this leads to more packages making their way from server:php:extensions to server:php:extensions:php7 (assuming that’s what we’re supposed to use?). BTW, that repo has 3 packages named php5-* — old packages which should be purged? There are corresponding php7-* packages. -Andrew

3 years, 3 months

[opensuse-packaging] New packaging guidelines for PHP7 pacakges

by Johannes Weberhofer

Dear all! With request https://build.opensuse.org/request/show/519119 I propose to enhance and simplify the PHP7 packaging process. I have written the following comment to the request which can be commented there. You can also respond to that E-Mail. Please let me know what you think about it. As there are many PHP7 packages to be prepared and several requests are already waiting we should process quickly. I think we should not simply rename the old packages as most of them are completely outdated versions and packaged very complicated! *** This request improves compatibility to Fedora and simplifies packaging a lot. What is contained in the request? * php7-macros and php5-macros contains new packaging macros which makes packaging more simple, Have a look at the macros.php. I will check that those macros will be included in php5 and php7 packages in the future, but until that's done the macros can must be included in the spec files. Currently "BuildRequires: %{php_name}-macros" is required, but this can be moved to the "%if 0%{?suse_version} < 1320" as soon as PHP7 has been updated in factory Current openSUSE Versions require "BuildRequires: %{php_name}-pear-Archive_Tar" to be included. I have already submitted a fix to factory so new versions will no longer need that I highly vote for removing all those lower-case Provides/Obsoletes; let's just use the original package's name! For the future we should create virtual provides using the upstream names: Provides: php-pear(Auth_SASL) = %{version} Related to this, the old php-macros project can be deleted. Therefor I have created https://build.opensuse.org/request/show/519123 I have attached an working example in: php7-pear-Auth_SASL If you have no objections, I'd accept the changes to server:php:applications and prepare a request for future inclusion of the macros into factory and update the wiki pages. *** -- 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

3 years, 3 months

[opensuse-packaging] Mixed license problem

by Luigi Baldoni

Hi all, I'm trying to get a package into Factory but legal says there's a problem with the embedded proprietary artwork licensing terms. Said material is indispensable to the program. Upstream tells me they could relicense it under CC-BY-ND-4.0, with the rest of the code being GPL-3.0 or LGPL-3.0: were this the case, would Factory accept it? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/Mixed-license-problem-tp5094424.html 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

3 years, 3 months

[opensuse-packaging] call for volunteers: singlespec auto-conversion

by jan matejek

Hello all, I have finally done what I promised several months ago and ran an auto-converter over all python-* packages in Factory. The results can be seen in: https://build.opensuse.org/project/show/devel:languages:python:singlespec-s… It is roughly 540 packages, so a small fraction of d:l:py :) About a third of them build. Another third fails. The rest is stuck in unresolvable state, usually because they depend on something from the failed set. Now is the time to review the packages and decide what to do with them. And I'd like to ask you for help with this gargantuan task. I'm taking time off tomorrow, so I won't be handling any SRs until Monday. But I wanted to show you this anyway, in case you felt like playing with it over the weekend. Also, I think d:l:py maintainers have rights to the repository? (I honestly don't know how to organize stuff like this, so for now, I'm leaving it as-is and seeing what happens. I'll do more on Monday. Maybe some sort of a hackathon? Bruno Friedman (in cc) was talking about this...) Anyway. What needs to be done: * Some packages simply aren't compatible with python3. These should either be upgraded to a compatible version, dropped from Factory altogether, or left alone with an added Provides for "python2-foo". * (This also holds for various backports and things like configparser, unittest2 etc. We generally don't want them in singlespec versions if they aren't necessary for Python 3.4 and above.) * In others, the autoconverter might have messed up. Maybe the spec file needs a human touch to bring it to a working state. * Even packages that build successfully must be reviewed to check that post-conversion spec file is doing the same thing as the pre-conversion one. * Some packages got there by mistake (such as -doc specs of packages that are already singlespec) and can be deleted from the singlespec-staging project * This is also a good opportunity to drop obsolete stuff. For instance, Factory still contains python-argparse, which has not been necessary since openSUSE 12.1 (because it's in stdlib of all shipped pythons). Worse, packages still list is as a requirement. This needs to go. * When a package is reviewed, it should be submitted to its devel project (and deleted from singlespec-staging when the request is accepted) and then forwarded to Factory. Successfully singlespec'd packages also need a corresponding delete request for the python3 counterpart. All in all, thanks in advance to every volunteer. Every single SR helps :) regards m.

3 years, 3 months

[opensuse-packaging] devel:languages:python:legacy proposal

by Todd Rme

There are a lot of packages in devel:languages:python that are simply unmaintained. Upstream will never update them to support python3. This is both a maintenance burden and a potential security issue. So I suggest wherever possible we move away from these packages. When we can they should be removed from factory and removed as (optional) dependencies for other packages. I also suggest that we create a new subproject for devel:languages:python, perhaps devel:languages:python:legacy, where these packages can live. Of course packages that are needed for other packages, or packages that are maintained but python2-only, will remain as-is. This is only for packages that have not seen upstream activity for, say, 3 years, and don't support modern versions of python3 (3.4+). I would be against dropping the packages entirely as long as they still work. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 3 months

[opensuse-packaging] what happened to glibc's xlocale.h

by Dave Plater

Hi, at least three packages, shotcut, libmlt and it's linked webvfx, that were just accepted into Factory fail to build due to a missing xlocale.h in glibc-devel. Can anybody shed any light on what's happened so I can fix it? Thanks Dave -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 3 months

[opensuse-packaging] alternative "Requires:" - how?

by Werner Flamme

Hi, I want to provide a package, DokuWiki. This package requires PHP Version 5.6 or later. To produce a package realizing this requirement, I tried Requires: (php5 >= 5.6 or php7) which I read on <http://rpm.org/user_doc/boolean_dependencies.html> as a way to do this. But OBS told me that Requires: are not allowed to start with "(", so I replaced it by Requires: php5 >= 5.6 or php7 and now zypper tells me that "nothing provides or needed by DokuWiki-2017.02.19e-9.1.noarch" :) So, how can I set alternatives for "Requires:"? Well, for this package I can set Requires: php >= 5.6 Requires: mod_php_any >= 5.6 but is there a more general solution as described for rpm4 three years ago? Werner --

3 years, 3 months

[opensuse-packaging] Python packages naming rules

by Sebastian

Hi, I wonder how python packages should be named as there are two conflicting naming conventions. As an example I am using the case of the python library/program gogs-client, see the declined request [1] First there are the generic naming guidelines which say that the dash '-' must not be used "as the delimiter for name parts".[2] However it is not very clear to be what name parts are in this context. Are "python" and "gogs-client" name parts or are "gogs" and "client" name parts? Then there is the more specific naming policy for python packages which says the package must be called "python-$pypiname". It does not mention any exceptions (at least I haven't found any). In the above example the pypi's name is "gogs-client" and results in I'd assumed that the more specific rule wins. However, do these two rules interfere in some way? Or have the rules been changed? When looking at existing packages I get the impression that the policy for python packages is the active one (e.g. look at all the "python(2|3)?-python.*" packages). Sebastian [1]: https://build.opensuse.org/request/show/517141 [2]: https://en.opensuse.org/openSUSE:Package_naming_guidelines#Separators [3]: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers

3 years, 3 months

[opensuse-packaging] Creating meta-packages for python2/3 from a single spec

by John Paul Adrian Glaubitz

Hi! I am in the situation where I need to build two meta-packages from a single spec file, one being named python2-$UPSTREAMNAME and the other being named python3-$UPSTREAMNAME. These packages are supposed to pull the same set of packages, with the only difference that python2-$UPSTREAMNAME pulls in the python2- packages while python3-$UPSTREAMNAME pulls in the python3- packages. The python2- and python3- binary packages are also created from a single spec file, one example is python-azure-batch which can be found in [1]. In this spec file, I'm using %python_subpackages from python-rpm-macros to generate the python2- and python3- binary packages. I tried using this technique for the meta-package as well. However, that didn't work because python-rpm-macros expects a setup.py to be present which, of course, I don't have in an effectively empty package. So, I am wondering whether anyone has a clever idea how to solve this issue. I would know how to do it for a Debian package, but my RPM background is not yet proficient enough to come up with a solution for RPM :). Thanks, Adrian > [1] https://build.opensuse.org/package/show/devel:languages:python/python-azure… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 3 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging August 2017