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
> 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
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
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
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.
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
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
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
--
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
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