Hi,
just wanted to ask if/when you are planning to add RHEL 8?
As of https://developers.redhat.com/blog/2019/05/07/red-hat-enterprise-linux-8-no…
RHEL 8 was released on May 7, 2019
Regards,
Stephan Dühr
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi,
our unstable versions of osc and build script have some new options
where I would like to gather some more experiences.
1) osc shell [--vm-type=VM] [REPOSITORY ARCH]
creates or jumps into the build environment. This works independend
of the used VM mode, so using it with image based VMs like KVM
should become WAY more handy now.
The old "osc chroot" is obsoleted by this, but basically doing the
same as "osc shell" for chroot.
2) Building for foreign architectures using qemu system emulator.
osc is offering now to use any hardware architecture. (Thanks a lot Guillaume
for the initial implementation of that code!). For example
osc build --vm-type=qemu openSUSE_Factory_ARM aarch64
will build for aarch64 on your x86_64 workstation for example.
But it should work for any architecture.
The downside (compared to our former qemu user land emulation)
is that it works way slower due to emulation overhead and it
works currently only in projects where a kernel-obs-build is defined.
But it should allow everybody to build at least for openSUSE
and SUSE SLE armv7l, aarch64, ppc*, s390*, riscv64 and so on
architectures.
3) osc wipe
for easy cleanup of your build environment.
I am still improving documentation and will blog about it after
we released official updates. For now you need to use
osc
build
packages from OBS:Server:Unstable project to test it. But I would definitive
love to have some feedback!
thanks
adrian
PS: someone broke the CI version in devel:tools:scm project, so you need to
switch to OBS:Server:Unstable in case you are used to get it from there.
--
Adrian Schroeter <adrian(a)suse.de>
Build Infrastructure Project Manager
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
(HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi,
On an x86-64 openSUSE Leap 15.1 system I am trying to cross-build a
package with osc to Raspbian 9.0 arm7l using the following command
osc build Raspbian_9.0 arm7l
It fails with the following build log.
https://pastebin.com/raw/yQp0Kfyc
An attempt for Raspbian_10 fails in the same manner.
Any help would be appreciated.
Regards,
Mark
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi all,
I am having trouble getting packages to build on CentOS 8 Standard.
My simple C++ test package (home:Zanchey/c11test), plus other packages I
have tried, fails with:
+ /usr/lib/rpm/find-debuginfo.sh -j8 --strict-build-id -m -i --build-id-seed 1-23.1 --unique-debug-suffix -1-23.1.x86_64 --unique-debug-src-base c11test-1-23.1.x86_64 --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 -S debugsourcefiles.list /home/abuild/rpmbuild/BUILD/c11test-1
extracting debug info from /home/abuild/rpmbuild/BUILDROOT/c11test-1-23.1.x86_64/usr/bin/c11test
*** ERROR: GDB index requested, but no gdb-add-index installed
error: Bad exit status from /var/tmp/rpm-tmp.Xn1JEf (%install)
Do I need to add a build dependency on GDB, or add something to the
project configuration? Any advice is appreciated.
Thanks
David Adam
zanchey(a)ucc.gu.uwa.edu.au
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Does the publisher support some sort of "lingering" for already published, but stale, packages? If a republish of the repository happens after libzypp has downloaded the metadata, but before it actually downloads the binary package, the attempted download fails with ENOENT because the old package will be just removed. It would be cool if the old binaries will remain for a short period of time until they are finally wiped from the download repository.
Neither YaST nor libzypp handles such ENOENT, as a result unattended installations will run into a hard error.
It will eventually help if the published binary packages do not change name. I think it will be more robust if they are published as 'arch/name.rpm' instead of 'arch/name-version-revision.arch.rpm'. Does the publisher support that?
Olaf
I am able to build 64 bit Wine packages for Fedora 31 on https://build.opensuse.org/package/show/Emulators:Wine:Fedora/wine-devel, but when I try to build them locally it fails with:
Verifying integrity of cached packages
using keys from Fedora:31
warning: /var/tmp/osbuild-packagecache/Fedora:31/standard/x86_64/acl-2.2.53-4.fc31.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 3c3359c4: NOKEY
/var/tmp/osbuild-packagecache/Fedora:31/standard/x86_64/acl-2.2.53-4.fc31.x86_64.rpm : public key not available
The last line is repeated for multiple packages.
I can get past that by adding --no-verify to the command, but then the build fails with
[1/68] preinstalling filesystem...
[ 1s] bsdtar: Error opening archive: Unrecognized archive format
[ 1s] [2/68] preinstalling libgcc...
[ 1s] bsdtar: Error opening archive: Unrecognized archive format
with the bsdtar error repeated for multiple packages.
I am able to build Fedora 30 packages both locally and on the OBS using the same spec file.
--
Rosanne DiMesio <dimesio(a)gmail.com>
--
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 new and trying local build on s390x with SLE_12_SP3 using the
following command
sudo osc build
but I get the public key not available for many packages. You can see
the output by clicking the following link
https://pastebin.com/YBQk3vGe
I know that I can use --noverify option to bypass this and builds
complete successfully when I use --noverify option but how can I fix
this? What will happen if I don't fix it?
--
Usman
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Ubuntu 19.10 is missing an prefer:
have choice for fakeroot needed by devscripts: fakeroot pseudo
Regards,
Martin
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hello List,
Our product team(s) want to generate product (:GA) builds from 2 (or
more!) SCM branches at any given point. I'm not referring to
Maintenance updates (:Update) projects, but the :GA project.
Here's the workflow and requirement:
1. Development of GA release happens on "trunk" (in SVN and "master"
in git terminology)
2. When we are close to a milestone, for example, a Beta drop, we
branch trunk so that only Beta showstoppers (or ship stoppers,
whichever you prefer) are checked into this new branch.
3. The "trunk" is open for next milestone changes.
Requirement is to generate builds from both these branches - trunk and
beta.
Right now, we have been creating a "home" project [1] to build code
from trunk during the "Beta phase". The official :GA project contains
source code from the corresponding "Beta" branch. But this is not being
accepted as a solution because:
* GPG keys for home projects and GA project are different
* We do not build product ISO from home project [2]
* Package versions diverge between GA and home project
I'm writing here to seek any possible solutions that will help solve
the above problems. I have been trying to evaluate if Staging projects
could help solve this problem, but I'm unable to visualize or
understand a typical workflow using Staging projects.
Any tips or suggestions on how to move forward would be greatly
appreciated.
Regards,
Srinidhi.
[1] We could also create :GA:BetaX (where X is the n'th Beta we are
working on) to solve the GPG keys problem but I don't think (or know)
how to solve the version divergence.
[2] We don't build ISO because Build Service adds the home project into
product and package tracking database. I don't know if this is a
problem or not, but when "osc sm <package>" lists a home project, it
might cause confusion - something I would like to avoid.
Hi
I activated the CentOS 8 build target.
However, any package requiring python (2) reported it is unresolvable.
So i edited the spec file to use python2 or python27. These packages are
available on a CentOS 8 system. But in the buildservice they are still
reported as unresolvable.
Any suggestions how to get my python 2 packages to build on CentOS 8?
Regards
--
Mathias Radtke
opsi - Open PC-Server-Integration
das Open Source Client-Management-System von uib gmbh
Birgit Hubal
Vertrieb / Projektkoordination
eMail: b.hubal(a)uib.de
Tel. +49 6131 / 27561-18
Fax +49 6131 / 27561-22
uib gmbh
Bonifaziusplatz 1B
55118 Mainz
Internet:
https://uib.dehttps://opsi.org
Geschäftsführer: Dr. Detlef Oertel, Erol Ülükmen
Handelsregister: Amtsgericht Mainz HRB 6942
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
