I need published binaries for testing, but the prj never reaches state "published" because something causes a constant rebuild in home:olh:bug1100408:sle12sp2. Any idea what is wrong with OBS/SUSE:SLE-12-SP2:Update?
Olaf
Hi!
It has been quite a lot of time since the last OBS frontend Sprint
report, but you can now read about all we did the last two sprints: the
new bug squad role, the bundle gems service, the pattern library,
attending Brighton Ruby and much more! ;)
https://openbuildservice.org/2018/07/17/sprint-report-41-42
Enjoy reading it! :)
The OBS Frontend Team
--
Ana María Martínez Gómez - ammartinez(a)suse.de | ammartinez(a)suse.com
BuildService Engineer
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Building SLE12 docker images fails if a package to be installed into the images requires an absolute path, instead of an ordinary rpm resolvable. How is this supposed to be fixed in the repo metadata? FileProvides is probably not going to work.
In my case zypper does not know that /usr/bin/gconftool-2 comes from gconf2.
Olaf
There's a closed issue that i wrote earlier on a github: https://github.com/openSUSE/open-build-service/issues/5360.
Can someone tell it is me doing something wrong or it's a bug in OBS? The description of a problem linked above. Thank you.
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi,
Now we have libqt4 4.8.7 version in updates repository, but libqt4 4.8.6
in main openSUSE Leap 42.3 OSS repository. Because of libqt4 update,
qt4-style-fusion package (from OBS home:embar-:Lietukas repository) is
in conflict, because it requires libqt4 4.8.6. After try to rebuild
package, it still use libqt4 4.8.6 for building, not 4.8.7 version:
[ 13s] [161/327] cumulate libqt4-4.8.6-16.6
...
[ 13s] [326/327] cumulate libqt4-devel-4.8.6-16.6
Meta Configuration of project contains
<repository name="openSUSE_Leap_42.3">
<path project="openSUSE:Leap:42.3" repository="standard"/>
<arch>x86_64</arch>
</repository>
What to do (/ how) to include openSUSE update repository for sources of
package's building?
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
I noticed that gcc-5 became broken just after changing
project="openSUSE:Leap:42.3" into project="openSUSE:Leap:42.3:Update" in
OBS project Meta configuration.
While using <path project="openSUSE:Leap:42.3" repository="standard"/>:
[ 66s] -- The C compiler identification is GNU 5.3.1
[ 66s] -- The CXX compiler identification is GNU 5.3.1
[ 66s] -- Check for working C compiler: /usr/bin/gcc-5
[ 66s] -- Check for working C compiler: /usr/bin/gcc-5 -- works
While using <path project="openSUSE:Leap:42.3:Update" repository="standard"/>:
[ 66s] -- The C compiler identification is unknown
[ 66s] -- The CXX compiler identification is unknown
[ 66s] -- Check for working C compiler: /usr/bin/gcc-5
[ 66s] -- Check for working C compiler: /usr/bin/gcc-5 -- broken
...
[ 67s] gcc-5: error: unrecognized command line option '-fstack-clash-protection'
Spec file contains:
BuildRequires: gcc5-c++
...
%build
export CC=gcc-5
export CXX=g++-5
...
In both builds I see cumulate gcc5-c++-5.3.1+r233831-10.3, thus problem
seems not to be in this package itself, but maybe in some comfiguration?
How to prevent this issue?
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi,
I am trying to build cacti for s390x SLE_12_Backports.
osc build --local-package --clean --noverify SLE_12_Backports s390x *.spec
Although, I get the rpms
/var/tmp/build-root/SLE_12_Backports-s390x/home/abuild/rpmbuild/SRPMS/cacti-1.1.38-0.src.rpm
/var/tmp/build-root/SLE_12_Backports-s390x/home/abuild/rpmbuild/RPMS/noarch/cacti-1.1.38-0.noarch.rpm
/var/tmp/build-root/SLE_12_Backports-s390x/home/abuild/rpmbuild/RPMS/noarch/cacti-doc-1.1.38-0.noarch.rpm
But, osc results return a failed build.
SLE_12_Backports s390x failed
Why is it so? The VM is being killed by the WATCHDOG. The log is
available on following link
https://pastebin.com/R4AtPDna
Can someone guide me on this?
--
Usman
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hello/
I want to build image against my local project repo. Still cant understand how to specify repositories in a .kiwi description. Is it should be direct links like "http://myrepo.local" or something like "obs://myproject/standard"? Tried both but pkg status still "broken"...
There's log entries from scheduler_x86_64.log, where "livecd" is my pkg proj name:
"livecd (repo url not using obs:/ scheme: obsrepositories:)"
Thanks.
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi all,
on a internal customer OBS instance we noticed that KIWI docker images
(type=docker) are no longer xzipped, i.e. we get a uncompressed tarball.
I am still gathering all the details, but it seems like the last step in
KIWI (tar'ing up all directories) is correctly executed with -cJf
/path/to/docker/image.tar.xz, but after that I only see image.tar with
sha256sums and packages files.
We are not sure if this is related to the OBS update to 2.9.3, or if
this is something inside kiwi. But as the image definitions did not
change, this could only be due to some Prefers added to the prjconf, as
we noticed some more ambiguities for these images ("have choice for...").
Anyone else seeing this? Known issue? Where could I start digging?
Thanks in advance.
Johannes
--
Johannes Kastl
Linux Consultant & Trainer
Tel.: +49 (0) 151 2372 5802
Mail: kastl(a)b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537