March 2022 - openSUSE Build Service - openSUSE Mailing Lists

Re: osc branch of revision results in error
by Axel Braun 29 Mar '22

29 Mar '22

Hi Adrian, Am Dienstag, 29. März 2022, 16:33:29 CEST schrieb Adrian Schröter: > On Dienstag, 29. März 2022, 16:29:16 CEST Axel Braun wrote: > > Hi Adrian, > > > > Am Dienstag, 29. März 2022, 16:10:24 CEST schrieben Sie: > > > On Dienstag, 29. März 2022, 16:07:13 CEST Axel Braun wrote: > > > > Hi, > > > > > > > > when I branch an earlier revision of a package like > > > > > > > > osc branch -r 36 -f devel:languages:python python-cairocffi <target> > > > > > > that revision points to the current revision of the package in > > > openSUSE:Factory. > > > > The version in Factory is the latest - rev. 39 in d:l:p > > exactly, but you can merge that one into the old 36 revision. And how? > > > So this is causing this conflict: > > > > I get the error: > > > > > > > > BuildService API error: failed to branch: conflict in file python- > > > > cairocffi.spec > > > > > > > > Well, it is expected that the spec file of the reveision deviates from > > > > the > > > > actual package. So how can I branch an earlier version? > > > > > > You need to have a mergeable revision or in most cases just pick one > > > from > > > > > > osc buildhist ... > > > > osc buildhist devel:languages:python python-cairocffi 15.4 x86_64 > > time srcmd5 vers-rel.bcnt > > rev duration > > 2022-01-10 14:57:01 1843103fad445f3d497afca4bae8a582 1.3.0-43.1 > > 39 53 > > 2022-01-14 18:43:47 3e7538a12438c0f6d38af68f07bca8e6 1.3.0-44.1 > > 39 75 > > 2022-02-09 07:31:29 3e7538a12438c0f6d38af68f07bca8e6 1.3.0-44.2 > > 39 41 > > > > -> all of the current release, that will not help > > 15.4 is a new repo, check with 15.3 repo. That goes back to rev. 38, but not beyond (tried with a higher -l as well) Cheers Axel

2 1

osc branch of revision results in error
by Axel Braun 29 Mar '22

29 Mar '22

Hi, when I branch an earlier revision of a package like osc branch -r 36 -f devel:languages:python python-cairocffi <target> I get the error: BuildService API error: failed to branch: conflict in file python- cairocffi.spec Well, it is expected that the spec file of the reveision deviates from the actual package. So how can I branch an earlier version? Cheers Axel

2 1

My armv7l worker is not used :-(
by Stefan Seyfried 28 Mar '22

28 Mar '22

Hi all, I'm trying to beef up the packman arm workers with my army of unused raspberry pi's. The "primary" host is a raspberry pi400 (aarch64) running Leap 15.3, which works reasonably well as a KVM builder. First tries have been made with a raspberry pi3 (aarch64) running Tumbleweed, which also works good, albeit slower due to the USB2 ports for storage. Now as the raspberry pi3 is a bit more useful for non-buildservice work as another spare raspberry pi2, I'd like to add the raspberry pi2 as a dedicated armv7l builder so that the pi400 has less packages to chew at the end of the day and the overall rebuild times will be a bit better. Unfortunately, the raspberry pi2 is recognized, but does not get any packages scheduled for build: seife@strolchi:~> osc -A pm workerinfo armv7l:seife-raspi2:1 <worker hostarch="armv7l" registerserver="http://10.8.0.1:5252" workerid="seife-raspi2:1"> <sandbox>lxc</sandbox> <linux> <version>5.16.14-1</version> <flavor>lpae</flavor> </linux> <hardware> <cpu> <flag>half</flag> <flag>thumb</flag> <flag>fastmult</flag> <flag>vfp</flag> <flag>edsp</flag> <flag>neon</flag> <flag>vfpv3</flag> <flag>tls</flag> <flag>vfpv4</flag> <flag>idiva</flag> <flag>idivt</flag> <flag>vfpd32</flag> <flag>lpae</flag> <flag>evtstrm</flag> </cpu> <processors>4</processors> <jobs>4</jobs> <memory>896</memory> </hardware> </worker> Still, it is apparently not acceptable as a worker: seife@strolchi:~> osc -A pm checkconstraints \ Multimedia yamdi openSUSE_Tumbleweed armv7l Worker ------ aarch64:hctw01:1 aarch64:hctw01:2 aarch64:hctw01:3 aarch64:n1sdp:1 aarch64:n1sdp:2 aarch64:seife-raspi3:1 aarch64:seife-raspi3:2 aarch64:seife-raspi3:3 aarch64:seife-raspi3:4 aarch64:seife-rpi400:1 aarch64:seife-rpi400:2 aarch64:seife-rpi400:3 The raspberry pi3 has the following workerinfo: seife@strolchi:~> osc -A pm workerinfo aarch64:seife-raspi3:1 <worker hostarch="aarch64" registerserver="http://10.8.0.1:5252" workerid="seife-raspi3:1"> <sandbox>kvm</sandbox> <linux> <version>5.16.14-1</version> <flavor>default</flavor> </linux> <hardware> <cpu> <flag>fp</flag> <flag>asimd</flag> <flag>evtstrm</flag> <flag>crc32</flag> <flag>cpuid</flag> </cpu> <processors>4</processors> <jobs>2</jobs> <memory>444</memory> <swap>1024</swap> <disk>4096</disk> </hardware> <job>Multimedia::openSUSE_Tumbleweed::apache2-mod_musicindex-ba4acdf0de3aa9a378cc9256452fde65</job> <arch>armv7l</arch> <jobid>62b2b315e5b816a4ed9f71f7cda0edbf</jobid> </worker> I'm actually not sure if the lxc setup on the pi2 is correct, but since it does not even get a single build job scheduled, this should not yet matter. It also does not get anything with "chroot". Can I find out anything about the problem from my side or can only the PMBS admin investigate the issue (in that case, I'd probably try to set up my own OBS instance for investigation)? Thanks, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

3 5

Request to add repositories for 32 bit packages for AlmaLinux
by James Guana 28 Mar '22

28 Mar '22

I am trying to build an i686 package in AlmaLinux but could not do it. I trying adopting your Meta Config in your AlmaLinux8 project but it asks me of Admin rights. So far, AlmaLinux have i686 packages that is stored in x86_64 url. Can you please add i686 repository to: https://build.opensuse.org/project/show/AlmaLinux:8

2 1

Are Leap workers stalled?
by Nicolas Formichella 23 Mar '22

23 Mar '22

I have pushed a revision (revision 5) on my branch at https://build.opensuse.org/package/show/home:stig124:branches:Base:System/d… Although Factory, TW and SLE12 responded correctly to the source change and built the package, neither Leap nor SLE 15 had relaunched a build, and they appear with a red warning sign. I tried cleaning the binaries (which worked), but the build never started, even with a force re-trigger on each arch, they're all stuck on the last (revision 4) build with no possibility of retriggering the build. Is there something that can be done for that to build, so that I can send my request after a successful build Regards, Nicolas FORMICHELLA stigpro(a)outlook.fr

2 2

Request to add repositories for 32 bit packahes for AlmaLinux
by DOMINIC P. GUANA 20 Mar '22

20 Mar '22

Hi, The 32 bit bit packages are located on the same directory as 64bits. I tried adding a 32 bit repository in my project through direct link but it requires an admin access so i could not complete my build. Can I please ask the Admin to add 32bit support for AlmaLinux? Regards, James Dominic Guana

1 0

QEMU cross build with osc
by Dirk Stöcker 18 Mar '22

18 Mar '22

Hello, in a package in home:dstoecker:base I do on an x86_64 system osc build --local-package -j 4 --vm-type=qemu --no-verify openSUSE_Leap_15.0_ARM armv7l package.spec that worked in the past, but now I get this: [ 1s] setting hostarch to armv7l [ 1s] booting qemu... [ 1s] Using UART console [ 1s] -nodefaults -no-reboot -nographic -vga none -runas qemu -net none -kernel /var/tmp/build-root/openSUSE_Leap_15.0_ARM-armv7l/.mount/boot/kernel -initrd /var/tmp/build-root/openSUSE_Leap_15.0_ARM-armv7l/.mount/boot/initrd -append root=/dev/sda rootfstype=ext3 rootflags=data=writeback,nobarrier,commit=150,noatime ext4.allow_unsupported=1 mitigations=off panic=1 quiet no-kvmclock elevator=noop nmi_watchdog=0 rw rd.driver.pre=binfmt_misc console= init=/.build/build -m 512 -drive file=/var/tmp/build-root/openSUSE_Leap_15.0_ARM-armv7l/img,format=raw,if=none,id=disk,cache=unsafe -device ,drive=disk,serial=0 -drive file=/var/tmp/build-root/openSUSE_Leap_15.0_ARM-armv7l/swap,format=raw,if=none,id=swap,cache=unsafe -device ,drive=swap,serial=1 -serial stdio -chardev socket,id=monitor,server,nowait,path=/var/tmp/build-root/openSUSE_Leap_15.0_ARM-armv7l/img.qemu/monitor -mon chardev=monitor,mode=readline -smp 4 [ 1s] /usr/lib/build/build-vm-qemu: line 210: -nodefaults: command not found [ 1s] No buildstatus set, either the base system is broken (kernel/initrd/udev/glibc/bash/perl) [ 1s] or the build host has a kernel or hardware problem... It seems there is a command name missing in 4th line. Does anybody know what goes wrong here? Using openSUSE Tumbleweed with following packages installed osc-0.176.0-1.1.noarch qemu-6.2.0-41.1.x86_64 qemu-arm-6.2.0-807.4.x86_64 rpm-build-4.17.0-1.1.x86_64 Freedom in Peace -- https://www.dstoecker.eu/ (PGP key available)

2 2

Ubuntu 22.04 DoD project broken for aarch64
by Jan Löser 17 Mar '22

17 Mar '22

Hi folks. On our OBS instance we introduced ubuntu:22.04 DoD project for x86_64 and aarch64. I took prjconf from https://build.opensuse.org/projects/Ubuntu:21.10/prjconf and this worked quite well for one or two months. Since 2022-03-08 in the morning the build results changed to "repository broken" for all repos (standard, universe, universe-update, update), but only for aarch64; x86_64 is still green. From the dodup.log I could see that something changed on the repo/mirror: 2022-03-08 01:24:02: [1528] checking ubuntu:22.04/universe/aarch64... updating metadata for deb repo at https://in.mirror.coganng.com/ubuntu-ports/jammy/universe ... 2022-03-08 01:25:00: [1528] checking ubuntu:22.04/standard/aarch64... updating metadata for deb repo at https://in.mirror.coganng.com/ubuntu-ports/jammy/main ... The repo/mirror itself seems to work correctly. Looking at packages build against ubuntu:22.04 DoD project, I see complains such as: <error>unresolvable: preinstalls: nothing provides perl-modules-5.32</error> I checked the repo and found perl v5.34, in prjconf I found the following specifying concrete perl version: ... Preinstall: sed gawk grep gzip debconf bash base-files base-passwd perl-modules-5.32 libperl5.32 ... Keep: m4 dpkg dpkg-dev libperl5.24 perl-modules-5.24 libdpkg-perl Doing s/5.32/5.34/g didn't help, only breaking x86_64, too. Do you have any tip/hint how to proceed here? Or where to look at for deeper debugging? Are there any binary packages cached for DoD? Thanks -- Jan

6 15

Manage Your Beta Features
by Dany Marcoux 17 Mar '22

17 Mar '22

Hey everyone, As part of the beta program, you can now manage your beta features. This allows you to disable a specific beta feature if somehow you don't want to use it. Details here: https://openbuildservice.org/2022/03/17/beta-features-management/ Enjoy! -- Dany Marcoux <dmarcoux(a)suse.de> Full Stack Web Developer - Open Build Service SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

1 0

AW: obsworker connecting to localhost:5352
by Mathias Radtke 15 Mar '22

15 Mar '22

> > Thus it seems like the DNS lookup did not work when the > > scheduler was started. Simply restarting the schedulers > > should fix this. > > The existing (broken) scheduled jobs also need to be removed. > > Which command removes the broken scheduled jobs? They are files in the /srv/obs/jobs/<arch> directories, just delete them with 'rm'. And I was looking for an osc option/function. Silly me. Thanks. After deleting those jobs and restarting the scheduler along with the workers it now builds again. Regards Mathias

1 0