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
Hi,
maybe we have a Java-Expert around that can support: projectlibre [1] suddenly fails to build on TW, with the error message:
[ 31s]
[ 31s] init:
[ 31s] [mkdir] Created dir: /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build
[ 31s] [mkdir] Created dir: /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/tmp
[ 31s]
[ 31s] build:
[ 31s] [javac] /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build.xml:30: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
[ 31s] [javac] Compiling 10 source files to /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build
[ 31s] [javac] error: Source option 1.5 is no longer supported. Use 1.6 or later.
[ 31s] [javac] error: Target option 1.5 is no longer supported. Use 1.6 or later.
[ 31s]
[ 31s] BUILD FAILED
As the version setting is not explicit mentioned in the spec file I guess it is some implicit definition.
Anyone an idea where to look forß
Thanks
Axel
[1] https://build.opensuse.org/package/show/Office/projectlibre
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Any Idea what that means "unknown host 'back-other-opensuse'" ?
---------- Forwarded Message ----------
Subject: Build failure of openSUSE:Tools/osc-plugin-install in Fedora_Rawhide/
armv7l
Date: Wednesday, 27 September 2017, 18:22:35 CEST
From: OBS Notification <admin(a)opensuse.org>
To: okurz(a)suse.de
Visit https://build.opensuse.org/package/live_build_log/openSUSE:Tools/osc-plugin…
Package openSUSE:Tools/osc-plugin-install failed to build in Fedora_Rawhide/
armv7l
Check out the package for editing:
osc checkout openSUSE:Tools osc-plugin-install
Last lines of build log:
unknown host 'back-other-opensuse'
--
Configure notifications at https://build.opensuse.org/user/notifications
openSUSE Build Service (https://build.opensuse.org/)
-----------------------------------------
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I have this package, foo-1.0, which provides /usr/bin/foo.
Then, I want to have foo-2.0 and bar-2.0 and make bar-2.0 provide
/usr/bin/foo. At the same time, I make foo-2.0 require bar-2.0.
However, if I do:
zypper install foo-1.0
zypper install foo-2.0
zypper install --old-version foo-1.0
I get this error that the file /usr/bin/foo creates a conflict between
foo-1.0 and bar-2.0. If I go on with the installation, I end up having
foo-1.0 and bar-2.0 installed.
Then, if I do
zypper install foo-2.0
I will get foo-2.0 installed, bar-2.0 remains (no new install) and
foo-1.0 gets removed. However, the latest, removing foo-1.0, causes
/usr/bin/foo to be removed as well!
Thus, I end up having foo-2.0, bar-2.0 but no /usr/bin/foo
How could I make installing foo-1.0 remove bar-2.0? So all this works?
thanks in advance
jordi
PD: substitute foo by docker, bar by docker-libnetwork, and /usr/bin/foo
by /usr/bin/docker-proxy ;)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
According to python packaging guidelines, python-based GUI
applications should not have the "python-", "python2-", or "python3-"
prefix. Ideally this wouldn't be a problem, since these are not
dependent on the python version they use. However, a lot of them turn
out to be either IDEs (e.g. Spyder), shells (e.g. jupyter's qtconsole
or bpython), or other development tools that are dependent on the
specific version of python they are built against.
Such packages are hard to use with singlespec macros. One option would
simply be to change or not follow the package naming guidelines for
such packages. Some packages, such as jupyter, do not follow them, but
others like spyder do.
Another option would be to make the macros more useful with such
packages. If we go this route, I see four changes that would be
extremely helpful in this regard.
First, it would be nice if %python_subpackages allowed us to specify
additional packages to manage. These would be packages named using
"%package -n foo" that we nevertheless want to have multiple versions
of. The macros would then create a set of packages
"foo-%{python_bin_suffix}". So for example we might say
%{python_subpackages spyder}. If we did that, we would get
"spyder-3.6" and "spyder-2.7", with Requires, Provides, Obsoletes, and
%files all handled appropriately for the given python version.
Second, it would be nice if there was some way to handle "%files -f
file". This is pretty much mandatory for -lang packages. So perhaps
something as bare-bones as allowing %files %{python_files foo -f
foo-%{$python_bin_suffix}.bar}, or something more advanced like
%{python_files foo -f foo.bar} which automatically inserts
%{$python_bin_suffix}
Third, it would be nice if %python_clone handled .desktop files and
appdata.xml files, or there was some alternative macro for these.
Fourth, it would be nice if there was a singlespec-aware version of
%find_lang and perhaps even %lang_package. %find_lang is easy enough
to handle manually with grep, but I have not found a good solution for
%lang_package.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
The new blender-2.79 has a compatibility problem with the previous
version. Do I simply use cat message file or echo in %postin to output a
warning message or is there another way?
Thanks
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi, I wanted to send a query to the mailing list, but I get the
following message:
Hi, this is the Mlmmj program managing the
<opensuse-packaging(a)opensuse.org> mailing list.
The message from <manuel(a)favf.mx> with subject "Two branches with the same
content different results (unresolvable)" was unable to be delivered to the
list because of an access rule set up by the list administrator.
(The denied message is below.)
What are the rules of the list to be able to send queries? Thank you
---------- Forwarded message ----------
From: <opensuse-packaging+owner(a)opensuse.org>
Date: 2017-09-15 14:06 GMT-06:00
Subject: Post to opensuse-packaging(a)opensuse.org denied: Two branches
with the same content different results (unresolvable)
To: manuel(a)favf.mx
Hi, this is the Mlmmj program managing the
<opensuse-packaging(a)opensuse.org> mailing list.
The message from <manuel(a)favf.mx> with subject "Two branches with the same
content different results (unresolvable)" was unable to be delivered to the
list because of an access rule set up by the list administrator.
(The denied message is below.)
---------- Mensaje reenviado ----------
From: MANUEL Q <manuel(a)favf.mx>
To: opensuse-packaging(a)opensuse.org
Cc:
Bcc:
Date: Fri, 15 Sep 2017 14:06:49 -0600
Subject: [opensuse-packaging] Two branches with the same content
different results (unresolvable)
Hello, I am new wanting to learn how to package in opensuse, if it is
not much trouble I would like to help me understand some issues.
As a practice, I decided to update the library:
https://build.opensuse.org/package/show/games/allegro52
>From which you create a branch by clicking from that address in
"Branch package". which I believe a subproject that would be as
follows:
https://build.opensuse.org/package/show/home:icomputo:branches:games/Allegro
Next data update the source code and the .spec file.
the result was:
openSUSE_Leap_42.2 x86_64 succeeded
openSUSE_Leap_42.3 x86_64 succeeded
openSUSE_Tumbleweed i586 succeeded
x86_64 succeeded
Then, since I do not expect it to be posted at
https://software.opensuse.org/search
I decided to make a new branch linked to the same project
../games/allegro52 from my home obs, which was thus:
https://build.opensuse.org/package/show/home:icomputo/Allegro
In the same files were uploaded as in the subproject
../home:icomputo:branches:games/Allegro
but in this case gave me errors, with the following result:
openSUSE_Leap_42.2 x86_64 unresolvable
openSUSE_Leap_42.3 x86_64 unresolvable
the question is, because being the two branches descending from the
same source, in the subproject if you find the library that has the
project where the branch is connected, and the project that is in
home: marks error of not finding the library.
They have the same files, they decide the two branches of the same
source project.
Could someone help me clarify that?
Thank you for the trouble of reading everything.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi, I wanted to send a query to the mailing list, but I get the
following message:
Hi, this is the Mlmmj program managing the
<opensuse-packaging(a)opensuse.org> mailing list.
The message from <manuel(a)favf.mx> with subject "Two branches with the same
content different results (unresolvable)" was unable to be delivered to the
list because of an access rule set up by the list administrator.
(The denied message is below.)
What are the rules of the list to be able to send queries? Thank you
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Crosspost on factory and packaging, please reply to factory...
######
Good evening everybody,
over the last couple of months I have been on and off with an
alternative approach to package vagrant.
First off: This might not the bee's knees and the best way of
packaging this. I also do not want to be rude to Duncan, Robert or the
others that have taken care of vagrant so far. I just wanted to put it
out there and get some opinions, if this might be a feasible approach
for the future.
For those not familiar with vagrant's packaging, the current package
- creates a rubygem in %build and then packages it for the default
ruby version hardcoded in the spec file and
- ignore's vagrants requirement for ruby2.2 so it is installable on
Leap 42.* which has ruby2.1.
I had some issues getting the plugin installation to work, and found
some things that I (as a not-ruby-expert) thought might be because of
this 2.1-vs-2.2 thing. But how to solve this issue for Leap 42.2,
which only has ruby2.1?
Yesterday (I hope) I got the builds working:
home:ojkastl_buildservice:Vagrant
Basically, you can install vagrant in the flavour for the ruby version
of your choice, which let's you install it with ruby2.4 on TW and
ruby2.2 on Leap. Or ruby2.3 or ruby2.5.
All dependencies that I found so far have been put into that project
and have being modified, where needed, to also build for more than one
ruby version. In my tests this worked, but then again one change
somewhere and everything falls apart... ;-)
Where possible I tried to narrow down the requirements so there should
not be any "have choice" errors. But, as each package actually is five
packages (one for each ruby in ruby{1,2,3,4,5}) with one status
(successful or failed).
Disclaimer: Due to the nature of ruby packages on the OBS it might
happen occasionally, that during updating or adding packages, some of
them might not get built for all ruby versions but are being shown as
successful in the webUI. So, in case you think there is something
missing, give me a call. (And, just to avoid misunderstandings, I
think the way to build ruby packages on OBS is pretty cunning, even if
there are corner cases now and then.)
So, I am looking forward to your thoughts and feedback.
Kind Regards,
Johannes
hello,
in my private code stash I now have the following RPM macro:
# (d)rop shebang (interpreter) line:
%update_shebang -d <files...>
# (s)et shebang (interpreter) line to /usr/bin/foo:
%update_shebang -s /usr/bin/foo <files...>
This is useful for python, but i don't want to put this in python-rpm-macros because it is going to
be useful for other packages and languages as well.
Instead I'd prefer to put this into /etc/rpm/macros.shebang, or /usr/lib/rpm/macros.d/macros.shebang
(which of the two is preferred these days btw?)
But I'm faced with the question of how to package it. ISTM this should be part of the default build
environment. If we need a BuildRequires: shebang-macros, we can as well stick with adhoc "sed"
invocations in every package.
So i'd create the shebang-macros package and add it as Requires for ... what? rpm-build? rpm itself?
Maybe instead add the macro to rpm and push upstream?
This fully implicit installation won't be portable to other distros though. What then, invoke the
macros always as %{?update_shebang:%update_shebang -d} ? That seems stupid.
Maybe I'd keep it as a requirement to python-rpm-macros, and other potential users (perl, ruby) can
add it as a requirement to their respective macro sets too?
what do you folks think?
m.