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