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
Dear Tumbleweed hackers and packagers,
It is about time that openSUSE:Factory aka Tumbleweed moves its
suse_version definition up again. There were quite some build hacks in
place that were explicitly pinned on 1330, as the idea was to be able
to get rid of them by the time we move the version.
As this is dragging on for too long though, we changed the hacks to
also apply on Tumbleweed with a newer suse_version and all those tweaks
are now in place. Which means we can move forward.
The new suse_version will be 1550 - starting with December 1st 2017
What's the rationale behind 1550:
* SLE15 / Leap 15 are using 1500 (for their entire lifecycle).
* Tumbleweed is supposed to be 'ahead of the game', so we plant it
between SLe/Leap15 and SLE/Leap16 (don't ask about timeframes for
those, nobody knows)
While packaging, you should never reference version 1550 though. your
thing are compatible to suse_version >= 1500 (meaning all Leap 15.x
versions) OR, if something comes into play on newer .x levels, you'd
do:
%if %{suse_version} > 1500 || %{sle_version} >= 150100
# Feature is available since Leap 15.1
BuildRequires: new-dep
%endif
This will indicate that starting with 15.1 things are present, and for
TW as well. If you don't know yet about the Leap version it might
become available, simply skip the sle_version check (but keep the check
for suse_version > 1500)
The change of suse_version has no visible impact to the end user, this
is merely of interest to developers/packagers.
Cheers,
Dominique
Hello guys,
I found no package for the virtualbox guest-tools for SLES12, so I
decided to try and build it. I took the leap 42.3 virtualbox package
and tried to get it to build the tools only.
With some fumbling I got it to build:
home:ojkastl_buildservice:Virtualbox_guest-tools_SLES12
I tried installing the packages (I am just after the no-X11-tools),
which worked.
Loading the kernel-modules failed, with an error that might be related
to wrong kernel version (or maybe not):
> # modprobe --allow-unsupported vboxsf
> modprobe: ERROR: could not insert 'vboxsf': Numerical result out of range
Same with vboxguest.ko. Same on SP3, SP2 and SP1. As this is the first
kmp package I am building, I am puzzled.
The error might be due to the fact that the modules are built for
kernel 4.4.73, while the machine run 4.4.92. But if I understand the
weak-updates links correctly, this should not matter.
Or did I build a wrong architecture by disabling the requirements for
gcc-32bit and xorg*-32bit (which was the only way I got the package to
build, as the guest-tools-x11 needs x11 dependencies obviously).
If anyone has a hint or RTFM or can have a look at the spec, this
would be highly appreciated.
Kind Regards,
Johannes
Hi,
as an occasional Java packager I'm trying to package jing and trang.
I've create a jing-trang package which lives currently here[1]. However,
I seek some expertise from a Java developer. :))
My package builds for Leap 42.2 and 42.3, but does not for
Tumbleweed. :-/ The ant process fails, see [2] for an overview. Here is
an excerpt from the problem:
[javac] warning: [options] bootstrap class path not set in conjunction
with -source 1.7.
I have a vague idea and searched the Internet for some solutions. It
seems, Tumbleweed contains Java 9, but compiling to a previous version
needs some other JAR file (rt.jar was mentioned).
On the other side, there is an additional error. OBS couldn't find
a class although they are found without any problems on Leap 42.2
and 42.3. This is the output:
[javac] /home/abuild/rpmbuild/BUILD/jing-trang-20151127/mod/rng-parse/src/main/com/thaiopensource/relaxng/parse/Context.java:3:
error: package org.relaxng.datatype does not exist
[javac] import org.relaxng.datatype.ValidationContext;
How do I solve it? Any idea?
Thanks for any pointers or suggestions, much appreciated! :)
---- References
[1]
https://build.opensuse.org/project/show/home:thomas-schraitle:java/jing-tra…
[2]
https://build.opensuse.org/package/live_build_log/home:thomas-schraitle:jav…
--
Gruß/Regards,
Thomas Schraitle
----------------------------------------------------------------------
SUSE LINUX GmbH (o<
Maxfeldstrasse 5 /\\ Documentation Specialist
90409 Nuernberg, Germany _\_v http://www.suse.comhttp://lizards.opensuse.org/author/thomas-schraitle/
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I've some trouble with building mksh on PPC64 and PPC64LE. Very often
it fails on PPC64 fails with:
FAIL ./check.t:heredoc-tmpfile-5
Description:
Check that heredoc temp files aren't removed too soon or too late.
Backgrounded subshell command with here doc
unexpected stdout - first difference: line 1, char 1 (wanted 'A', got 'L'
wanted:
A
hi
B
Left overs: *
got:
Left overs: *
A
hi
B
sometimes it works perfect. Also I see sometimes a similar defect on PPC64LE at
exactly the same check of the test suite of mksh.
All build systems seems to be based on qemu/kvm, nevertheless there seem to be
some differences but how to detect those (virt-what does report nothing).
Maybe it depends on the real host on which qemu-system-ppc64 or qemu-system-ppc64le
will be executed. It could be a defect of qemu based on the hosting system.
Do we have some real PPC64 and/or PPC64LE irons in our build farm or all hosts
based on qemu/kvm?
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
Hi,
currently, I'm facing the problem of how to merge two separate packages
into one. In my example, it's the (Java) packages jing and trang.
It doesn't make sense anymore to maintain them separately. Upstream
develops it in a single repository so it makes sense to do the same in
OBS.
So my idea was to combine both into a "jing-trang" package project on
OBS which creates the two RPM packages jing and trang as output. See [1]
for the details.
Now, I'm wondering how to proceed.
Should I submit the jing-trang to Java:packages first and do a delete
request for jing and trang afterwards? Or should there be a bug report
at the first place to refer to it in the changelog?
What's the preferred procedure here?
Thanks!
---- Reference
[1]
https://build.opensuse.org/package/show/home:thomas-schraitle:java/jing-tra…
--
Gruß/Regards,
Thomas Schraitle
----------------------------------------------------------------------
SUSE LINUX GmbH (o<
Maxfeldstrasse 5 /\\ Documentation Specialist
90409 Nuernberg, Germany _\_v http://www.suse.comhttp://lizards.opensuse.org/author/thomas-schraitle/
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Dear Tumbleweed hackers and packagers,
As you all know, python3 is 'the new thing' and pytho2 is being moved
to the background. Various packages have already been switched to be
using python3 - probably 'the easy ones' are all done. so we enter the
jounery of more complex things.
One such package is scons, which has been switched to be using python3
in request https://build.opensuse.org/request/show/542087
Now, scons is a bit 'special', as it is written in python and is
basiclaly compatible to python2 AND python3, BUT it parses
SConstruct/SConscript of different packages. And there the results are
a bit mixed when it comes to python3 compliance
Martin setup a test branch where he monitors all packages in
openSUSE:Factory using scons as their build script, see
https://build.opensuse.org/project/monitor/home:pluskalm:python3
Out of those only two packages are tracked as part of the rings (ffado
and gpsd), which means from a Factory process perspective, once those
two are fixed, the scons-switch to python3 could happen.
As this will impact some other packages, I'd like to ask for your help
to fix the other failing packages there. Simply branch them using "osc
branch openSUSE:Factory $pkg" and submit them back to their original
devel project. Martin's project only serves as monitor and should not
receive submissions.
In many cases, the issue in SConstruct are the usual python3 offenders:
print "FOO" needs to be written as print ("FOO") now; so patches can
turn out to be easy (in some cases they are more complex though)
This mail serves as an info so you won't be surprised when scons is
being merged and some packagaes stop building (of course some people
will still be surprised, but such is life)
Cheers
Dominique
Hi Packagers,
As previously discussed on the opensuse-packaging mailinglist, we are
moving our location of fillup-templates from /var/adm to /usr/share
https://lists.opensuse.org/opensuse-packaging/2017-11/msg00017.html
In order to do this as smoothly as possible we are using a new
%_fillupdir macro so spec files can inherit the new location, while
still defining the macro as the old location for older distributions
to not change anything there.
https://en.opensuse.org/index.php?title=openSUSE:Packaging_Conventions_RPM_…
As promised, this is the official notification that the new
%_fillupdir macro is now present in Tumbleweed and should be used in
all specfiles instead of /var/adm/fillup-templates
The original plan was going to require all package maintainers to
modify their specfiles to use the new macro.
However, while taking care of the packages I am interested in for
Kubic I decided to do the work for all 207 affected packages.
So package maintainers, all you should have to do is review & accept
the OBS Submit Requests from me referencing boo#1069468, the tracker
bug for this issue.
The submit requests include the compatibility definition for older
distributions.
Feel free to remove it if you do not need to build that package for
older distributions.
Please do what you can to accept and forward these requests to factory
as quickly as possible, especially for those packages also used by SLE
& Leap.
I am hopeful to get the btrfs subvolumes simplified once these changes
are complete, so I need your help to get these done promptly.
Thanks in advance,
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
During upgrade of postfix, nscd did not work properly because some
symbols are not available. I wonder what needs to be done to make nscd
available earlier during 'zypper dup'. The %pre/%post scripts in postfix
do not use it directly, but the used getent/useradd/... binaries may try
to use it. The Requires(pre/post) in postfix.spec are apparently ok,
except the incorrect conditional for getent. glibc was upgraded before
postfix, so this is not the issue here.
Upgrade was blocked by various bugs in the last months, they got fixed
only until very recently. Thats the reason for the huge jump forward.
Olaf
root@optiplex:~ # grep -E '(release-ftp|nscd|postfix|glibc)' /var/log/zypp/history
2017-05-30 09:29:56|install|linux-glibc-devel|4.11-1.1|noarch||oss|4e6cc97a31d9aa568a3d7966364eb0fac76ac5d4|
2017-05-30 09:30:33|install|openSUSE-release-ftp|20170524-1.1|x86_64||oss|8a907ed01f6f4d4ba30fc23484e222b605ef8b6c|
2017-11-23 09:26:35|install|glibc-debuginfo|2.26-7.1|x86_64||debug|d2a3893b076e3d0b50116a8f0bcd992ab5016b43|
2017-11-23 09:26:37|install|glibc-debugsource|2.26-7.1|x86_64||debug|4562bbb692a9d7a50554eaab6bed54ec1fbc7e6b|
2017-11-23 09:34:19|install|postfix-debuginfo|3.2.4-2.1|x86_64||debug|396a383e4310daeb766a9d2aa22e8f2b27a656a4|
2017-11-23 09:34:19|install|postfix-debugsource|3.2.4-2.1|x86_64||debug|8aea6966b0a34e1d406587048b84c1b5fac1b124|
2017-11-23 09:39:44|install|nscd-debuginfo|2.26-7.1|x86_64||debug|59888b3af71ece2c8f016f267f335944a759affe|
2017-11-23 09:39:46|install|glibc-locale-debuginfo|2.26-7.1|x86_64||debug|247d10317153d3d719fd2066722235ccb71cb59a|
2017-11-23 09:39:46|install|glibc-extra-debuginfo|2.26-7.1|x86_64||debug|3b582b7085c7298b92a484f67d5fc7ab1df846e7|
2017-11-23 09:43:45|install|openSUSE-release-ftp|20171121-1.2|x86_64||oss|4df1420c4ec3f828ac975fe628bf14cddf8e8b9b|
# 2017-11-23 09:44:07 glibc-2.26-7.1.x86_64.rpm installed ok
2017-11-23 09:44:07|install|glibc|2.26-7.1|x86_64||oss|dc1094b037c47c4244925d4609a18bbb79b504f8|
2017-11-23 09:44:50|install|glibc-locale|2.26-7.1|x86_64||oss|ab520862fe10de2be7f4b6c1a07c222e0de80a2e|
2017-11-23 09:45:24|install|glibc-32bit|2.26-7.1|x86_64||oss|8a1923d118bce00891b0a08df236aa832c1a5613|
2017-11-23 09:45:41|install|linux-glibc-devel|4.14-1.1|noarch||oss|03f07945f92efe01b28148e764c002e23b6f3ae7|
2017-11-23 09:46:40|install|glibc-locale-32bit|2.26-7.1|x86_64||oss|e0d925fdeb68ea286cd6b82e3527672f7bb7c9cb|
# /etc/permissions.d/postfix
# 2017-11-23 09:59:15 postfix-3.2.4-2.1.x86_64.rpm installed ok
# nscd: relocation error: nscd: symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
# nscd: relocation error: nscd: symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
# warning: /etc/postfix/main.cf created as /etc/postfix/main.cf.rpmnew
# /etc/postfix/postfix-files /etc/postfix/postfix-script
# /etc/postfix/post-install
# Updating /etc/sysconfig/postfix ...
2017-11-23 09:59:15|install|postfix|3.2.4-2.1|x86_64||oss|a1060870bc514f36d2f8426676227c27acb348ff|
2017-11-23 09:59:18|install|nscd|2.26-7.1|x86_64||oss|96365fe546123d842c94c0118ab60000c4075094|
2017-11-23 10:02:33|install|glibc-extra|2.26-7.1|x86_64||oss|25f1fa538db1d690d43e797a59de69a45e4e4876|
2017-11-23 10:02:36|install|glibc-devel|2.26-7.1|x86_64||oss|e68c0735b0c1f603649f3a85cc8e912fcdd574a2|
(Cross-posting, because I don't know if this is an OBS problem or
another crazy policy)
Today I found that my packages in home:seife:testing are almost all
gone, which prevented my daily "zypper -v dup --no-r
--no-allow-vendor-change" from completing successfully.
https://build.opensuse.org/project/show/home:seife:testing
All but one package in the Factory repo are "excluded" and apparently
there's no way to include them again.
How do I fix that?
--
Stefan Seyfried
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org