- openSUSE Build Service

Re: OBS rpm no public key
by Marco Moock 20 Mar '24

20 Mar '24

Am 20.03.2024 um 10:57:05 Uhr schrieb Adrian Schröter: > On Mittwoch, 20. März 2024, 10:24:14 CET Marco Moock wrote: > > Am 20.03.2024 um 08:08:23 Uhr schrieb Adrian Schröter: > > > > > On Dienstag, 19. März 2024, 16:59:20 CET Marco Moock wrote: > > > > Hello! > > > > > > > > Today I tried to use OBS to build for Fedora 39 on Debian > > > > Unstable (there runs osc). > > > > > > > > Verifying integrity of cached packages > > > > using keys from Fedora:39, OBS > > > > warning: > > > > /var/tmp/osbuild-packagecache/Fedora:39/standard/x86_64/alternatives-1.25-1.fc39.x86_64.rpm: > > > > Header V4 RSA/SHA256 Signature, key ID 18b8e74c: NOKEY > > > > > > > > What is the proper way to add these keys? > > > > Should I use rpm --import? > > > > I have tried that with the key from > > > > https://fedoraproject.org/fedora.gpg, but osc doesn't seem to > > > > care. > > > > > > > > What is the proper way to handle that? > > > > > > You are using a chroot build environment. This is not safe against > > > evil attackes, so you would need to trust these rpms via import. > > > > Which key do I need to import. From where do I get it? > > Usually from the distro. However, please note that this means > that anyone from Fedora can modify your Debian system. So the proper way is to use --vm-type? > Usually you do not want to grant this. Of course not. I though that the builds will be done in a separated environment independent of my current operating system. Thanks for the clarification. -- Gruß Marco Send unsolicited bulk mail to 1710928625muell(a)cartoonies.org

3 3

OBS rpm no public key
by Marco Moock 20 Mar '24

20 Mar '24

Hello! Today I tried to use OBS to build for Fedora 39 on Debian Unstable (there runs osc). Verifying integrity of cached packages using keys from Fedora:39, OBS warning: /var/tmp/osbuild-packagecache/Fedora:39/standard/x86_64/alternatives-1.25-1.fc39.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 18b8e74c: NOKEY What is the proper way to add these keys? Should I use rpm --import? I have tried that with the key from https://fedoraproject.org/fedora.gpg, but osc doesn't seem to care. What is the proper way to handle that? -- kind regards Marco Send unsolicited bulk mail to 1710863334muell(a)cartoonies.org

3 3

How to make a spec file specific for Leap repositories with their default numeric names?
by Paul McAuley 17 Mar '24

17 Mar '24

At https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.multibuild… it states "Specific files can be created to be built for a specific repository. Append the repository name of the build container behind the package name with a -. For example hello-openSUSE_13.2.spec. " This works in my package (https://build.opensuse.org/package/show/home:paul4us/klassy) for Fedora and Mageia. My problem is that I want to make a .spec file specifically for Leap 15.5 and Leap 15.6 but the default repository names are just "15.5" and "15.6" respectively. When I try to name a .spec file with packagename-15.5.spec or packagename-15.6.spec these spec files are ignored and the default packagename.spec is used instead, giving "unresolvable" statuses. I suspect that this is because the repository names are numeric with no letters. How do I make a .spec file specific to these 15.5 and 15.6 repositories? I don't want to make new repositories with a different name as people will be subscribed to the existing ones. Thanks, Paul

2 4

Problem with osc builds 15.6 Build 630
by Larry Finger 15 Mar '24

15 Mar '24

Hi, I am trying to build the virtualbox modules to check out [Bug 1221165] Can not install VirtualBox. Starting a VM gets a NULL request, but I do not have the debug info for the kernel module that breaks. When I try to ose osc to build it locally, I get the following: Verifying integrity of cached packages using keys from SUSE:SLE-15-SP3:Update, SUSE:SLE-15:GA, SUSE:SLE-15-SP4:GA, SUSE:SLE-15:Update, SUSE:SLE-15-SP6:GA, SUSE:SLE-15-SP4:Update, SUSE:SLE-15-SP5:Update, openSUSE:Backports:SLE-15-SP6, SUSE:SLE-15-SP5:GA, SUSE:SLE-15-SP3:GA, SUSE:SLE-15-SP1:Update, SUSE:SLE-15-SP2:Update, SUSE:SLE-15-SP2:GA, SUSE:SLE-15-SP1:GA, Virtualization warning: /var/tmp/osbuild-packagecache/SUSE:SLE-15-SP6:GA/toberemoved/x86_64/glibc-2.38-150600.6.2.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 3fa1d6ce: NOKEY /var/tmp/osbuild-packagecache/SUSE:SLE-15-SP6:GA/toberemoved/x86_64/glibc-2.38-150600.6.2.x86_64.rpm : public key not available /var/tmp/osbuild-packagecache/SUSE:SLE-15-SP6:GA/toberemoved/x86_64/sed-4.9-150600.1.3.x86_64.rpm : public key not available /var/tmp/osbuild-packagecache/SUSE:SLE-15-SP6:GA/toberemoved/x86_64/libselinux1-3.5-150600.1.45.x86_64.rpm : public key not available /var/tmp/osbuild-packagecache/SUSE:SLE-15-SP6:GA/toberemoved/x86_64/liblzma5-5.4.6-150600.1.16.x86_64.rpm : public key not available followed by a lot more messages. Is there a fix? Thanks, Larry

2 2

Open Build Service 2.10.22
by Daniel Donisa 15 Mar '24

15 Mar '24

Hello People, We have just released Open Build Service 2.10.22 which fixes security vulnerabilities. You should update your installations as soon as possible. ## Fixed Issues Frontend: * Update rack to version 2.2.8.1 - Fixed ReDoS in Accept header parsing [CVE-2024-26146] - Fixed ReDoS in Content Type header parsing [CVE-2024-25126] - Reject Range headers which are too large [CVE-2024-26141] DoS Vulnerability in Multipart MIME parsing. ## How to Update Package updates are available from the 2.10 repositories https://build.opensuse.org/project/show/OBS:Server:2.10 Fixed appliances can be downloaded from http://openbuildservice.org/download Kind regards, --- Daniel Donisa daniel.donisa(a)suse.com Build Solutions Team SUSE Software Solutions Germany GmbH

2 2

Incorrect perl dependencies for RHEL8/RHEL9
by obs＠dibo.sk 11 Mar '24

11 Mar '24

Hello, I managed to make builds for RHEL8/RHEL9 using private instance with development version of OBS. Unfortunately when building perl modules dependencies are not being calculated correctly. Looks like scripts generating perl dependencies aren't run. What is strange if I run it with rpmbuild even perl dependencies perl(ModuleName) dependencies are calculated correctly so I wandering if there's something special required in project config. Thanks for any hints Regards Dibo ⁣Get BlueMail for Android

1 0

AW: AW: Builds taking forever and not finishing
by Mathias Radtke 08 Mar '24

08 Mar '24

Hi, -----Ursprüngliche Nachricht----- Von: Adrian Schröter <adrian(a)suse.de> Gesendet: Donnerstag 7. März 2024 14:40 An: buildservice(a)lists.opensuse.org CC: Mathias Radtke <m.radtke(a)uib.de> Betreff: Re: AW: Builds taking forever and not finishing On Donnerstag, 7. März 2024, 12:13:42 CET Mathias Radtke wrote: > Hi, me again. > > So what I saw in the rep_server.log was > > > > 2024-03-07 10:14:13: [19782] maxchild limit reached > > 2024-03-07 10:14:13: maxchild limit reached > > and on a worker itself that sounds like hanging connections, as usually you should not run into that limit. bs_serverstatus /srv/obs/run/$each.status may give a hint. maybe strace also. today morning from the rep_server.log 2024-03-08 03:38:29: [1408] maxchild limit reached 2024-03-08 03:38:29: maxchild limit reached 2024-03-08 03:38:29: [2383] POST (192.168.109.104) /putjob?job=home:uibmz:opsi:4.3:experimental::OracleLinux_9::opsiconfd- 0b98dac035b76aa6d3f1eafc2db0f056&arch=x86_64&jobid=9c6195cc643e6683f85b447977a467d7&code=succeeded&now=1709869111&workerid=obsworker3:1 192.168.109.103 [15334]: unexpected EOF 192.168.109.103 [15334]: reply_error: write error: Broken pipe 2024-03-08 03:43:16: [2948] POST (192.168.109.102) /putjob?job=home:uibmz:opsi:4.3:experimental::Debian_10::opsiconfd- 0b98dac035b76aa6d3f1eafc2db0f056&arch=x86_64&jobid=0c3d18cf96add79b2aa6e13c6c682492&code=succeeded&now=1709869127&workerid=obsworker1:3 oops, we are not building (x86_64:obsworker1:3)? 192.168.109.102 [26950]: job is not building 192.168.109.103 [26905]: job is building on a different worker: obsworker2:3 -- obsworker3:2 192.168.109.102 [26950]: reply_error: write error: Broken pipe 192.168.109.103 [26905]: reply_error: write error: Broken pipe From the status call: obs:~ # obs_serverstatus /srv/obs/run/*.status R 6447 31072 POST (192.168.109.102) /putjob?job=home:uibmz:opsi:4.3:development::xUbuntu_20.04::opsi-linux-bootimage-944dcd1a0819f1b48108ca31e501ed12&arch=x86_64&jobid=134cd23c664a430b15928f7617e2f462&code=succeeded&now=1709867574&workerid=obsworker1:3 R 6439 31075 POST (192.168.109.102) /putjob?job=home:uibmz:opsi:4.3:development::Debian_10::opsi-linux-bootimage- 944dcd1a0819f1b48108ca31e501ed12&arch=x86_64&jobid=2e1cc3c3f0eefcd9e9eef86bb5556db8&code=succeeded&now=1709867582&workerid=obsworker1:1 R 170 14647 POST (192.168.109.103) /putjob?job=home:uibmz:opsi:4.3:experimental::SLE_15_SP2::opsi-utils-22f91c3a93baed82cc720da0b619a552&arch=x86_64&jobid=2986d91d30c5224023474f1da0326970&code=succeeded&now=1709869152&workerid=obsworker2:1 R 170 14645 POST (192.168.109.102) /putjob?job=home:uibmz:opsi:4.3:experimental::AlmaLinux_9::opsi-utils-22f91c3a93baed82cc720da0b619a552&arch=x86_64&jobid=aa701a1e0e3b4cffdbe8cd0bd9eb485b&code=succeeded&now=1709869140&workerid=obsworker1:1 and more. Regards Mathias

1 0

AW: Builds taking forever and not finishing
by Mathias Radtke 07 Mar '24

07 Mar '24

Hi Em qui., 7 de mar. de 2024 08:14, Mathias Radtke <m.radtke(a)uib.de <mailto:m.radtke@uib.de> > escreveu: Hi, me again. So what I saw in the rep_server.log was 2024-03-07 10:14:13: [19782] maxchild limit reached 2024-03-07 10:14:13: maxchild limit reached and on a worker itself rpc failed: socket write: Connection timed out sleeping one minute just in case... send_statehttp://obs.uib.gmbh:5252 <http://obs.uib.gmbh:5252> : rpc timeout Any suggestion what I might do ? Can you do a "curl -v http://obs.uib.gmbh:5252" from the worker? Maybe you're getting blocked traffic on either the worker or your main OBS? So got this on server and worker before restarting the obsrepserver.service obsworker2:~ # curl -vhttp://obs.uib.gmbh:5252 * Trying 192.168.109.101:5252... * Connected to obs.uib.gmbh (192.168.109.101) port 5252 (#0) > GET / HTTP/1.1 > Host: obs.uib.gmbh:5252 > User-Agent: curl/8.0.1 > Accept: */* > After restarting the obsrepserver.service I got this obsworker2:~ # curl -vhttp://obs.uib.gmbh:5252 * Trying 192.168.109.101:5252... * Connected to obs.uib.gmbh (192.168.109.101) port 5252 (#0) > GET / HTTP/1.1 > Host: obs.uib.gmbh:5252 > User-Agent: curl/8.0.1 > Accept: */* > < HTTP/1.1 200 OK < Content-Type: text/xml < Cache-Control: no-cache < Connection: close < Content-Length: 43 < <hello name="Package Repository Server" /> * Closing connection 0 This will now work for some time, worker finished packages will still end up in the rpc timeout. Regards Mathias

1 0

AW: Builds taking forever and not finishing
by Mathias Radtke 07 Mar '24

07 Mar '24

Hi, me again. So what I saw in the rep_server.log was 2024-03-07 10:14:13: [19782] maxchild limit reached 2024-03-07 10:14:13: maxchild limit reached and on a worker itself rpc failed: socket write: Connection timed out sleeping one minute just in case... send_statehttp://obs.uib.gmbh:5252 <http://obs.uib.gmbh:5252> : rpc timeout Any suggestion what I might do ? Regards Mathias Mathias Radtke Software Developer uib GmbH Bonifaziusplatz 1B 55118 Mainz E-Mail: m.radtke(a)uib.de <mailto:m.radtke@uib.de> Telefon: +49 6131 27561 0 https://uib.de https://opsi.org Sitz der Gesellschaft: Mainz Handelsregister: Amtsgericht Mainz HRB 6942 Geschäftsführer: Erol Ülükmen USt-IdNr.: DE 203 394 450 Save the Date: opsiConf in Mainz am 09. & 10. Juli 2024! Die Voranmeldung ist bereits eröffnet. opsi.org/opsiconf/ -----Ursprüngliche Nachricht----- Von: Mathias Radtke <m.radtke(a)uib.de> Gesendet: Donnerstag 7. März 2024 8:04 An: buildservice(a)lists.opensuse.org Betreff: Builds taking forever and not finishing Hi since yesterday we have a strange behaviour on our ptivate OBS instance. This instance links our packages published on the official OBS into our internal instance. The new updated packages get downloaded into our local instance. They are "finished" according to the log but then still having the "building" state. The time of the build continues also and it never reaches a success. Here's a Log from one of the workers [ 166s] obsworker1 finished "build opsi-linux-bootimage.spec" at Thu Mar 7 06:43:26 UTC 2024. [ 166s] 2024-03-07 07:43:26: finished 'opsi-linux-bootimage' for project 'home:uibmz:opsi:4.3:development' repository 'openSUSE_Leap_15.4' arch 'x86_64' build succeeded, send everything back... rpc failed: socket write: Connection timed out In addition in the UI monitoring the Repserver seems to die and the workers dissappear. Systemctl says the obsrespserver is running. Restarting it makes the workers appear again in the UI Montoring page, and they start building until the builds never finish again. Any suggestion what might cause the issue? Which log should I look into? Regards Mathias Mathias Radtke Software Developer uib GmbH Bonifaziusplatz 1B 55118 Mainz E-Mail: m.radtke(a)uib.de <mailto:m.radtke@uib.de> Telefon: +49 6131 27561 0 https://uib.de https://opsi.org Sitz der Gesellschaft: Mainz Handelsregister: Amtsgericht Mainz HRB 6942 Geschäftsführer: Erol Ülükmen USt-IdNr.: DE 203 394 450 Save the Date: opsiConf in Mainz am 09. & 10. Juli 2024! Die Voranmeldung ist bereits eröffnet. opsi.org/opsiconf/

2 1

OBS-built packages have other dependencies than installed distributions provide
by Florian Pose 07 Mar '24

07 Mar '24

Hello everybody! Every now and then we have the problem that packages that we are building in our Science:EtherLab repository [1] are built against newer libraries, that are not available on a live system (or in the current Docker image) and the packages are not installable. This problem recently appeared again (see two examples below). That leads us to the general question: Which paths must be configured for the repositories in OBS so that the same packages are available that are also available in a live installation or in a current Docker image? We keep stumbling across the fact that our packages built in the Science:EtherLab project cannot be installed because dependencies cannot be fulfilled. [1] https://build.opensuse.org/repositories/science:EtherLab # Example 1 (Container) Repository: Leap 15.4 (x86_64) Repository paths: - openSUSE:Leap:15.4:Update/standard Package: Data Logging Service (DLS) https://build.opensuse.org/package/show/science:EtherLab/DLS During the build process the build system pulls the library libprotobuf25 and creates a dependency to libprotobuf.so.25.1.0()(64bit) later on: [ 9s] [213/389] cumulate libprotobuf25_1_0-25.1-150400.9.3.1 https://build.opensuse.org/projects/science:EtherLab/packages/DLS/repositor… However, only the libprotobuf20 version is offered in the current container image, so the DLS package cannot be installed. $ docker pull opensuse/leap:15.4 $ docker run --rm -it opensuse/leap:15.4 e5757d974480:/ # zypper sh zypper> se -s protobuf2 ... S | Name | Type | Version | Arch | Repository --+---------------------+---------+---------------------+--------+------------------------------------------------------------- | libprotobuf20 | package | 3.9.2-150200.4.21.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 zypper> ar https://download.opensuse.org/repositories/science:/EtherLab/15.4 EtherLab zypper> ref ... zypper> in dls Resolving package dependencies... Problem: nothing provides 'libprotobuf.so.25.1.0()(64bit)' needed by the to be installed dls-1.6.1.g54c82b7-lp154.268.1.x86_64 The question: From where does it get the libprotobuf in version 25 instead of 20 when building and which additional path would we have to include? # Example 2 (Live system) Repository: Leap 15.3 (x86_64) Repository paths: - openSUSE:Leap:15.3:Update/standard Package: EtherCAT Master (ethercat) https://build.opensuse.org/package/show/science:EtherLab/ethercat During the build, the build system pulls a real-time kernel in version k5.3.18_8.13 and builds a KMP ethercat-kmp-rt-1.5.2.429.g3079ece_k5.3.18_8.13-lp153.385.3.x86_64.rpm https://build.opensuse.org/projects/science:EtherLab/packages/ethercat/repo… On a live system with Leap 15.3, this kernel 5.3.18_8.13 is not offered at all, only a 5.3.18-8.3.1: zypper> lr -u # | Alias | Name | Enabled | GPG Check | Refresh | URI ---+-------------------------------+---------------------------+-----------+-----------------+----------------+------------------------------------------------------------------------------- 1 | etherlab | etherlab | Ja | (r ) Ja | Ja | http://download.opensuse.org/repositories/science:/EtherLab/openSUSE_Leap_1… 2 | openSUSE-Leap-${releasever}-1 | openSUSE-Leap-15.3-1 | Nein | ---- | ---- | ftp://nas/opensuse/distribution/leap/15.3/repo/oss 3 | repo-backports-debug-update | Update repository with -> | Nein | ---- | ---- | http://download.opensuse.org/update/leap/15.3/backports_debug/ 4 | repo-backports-update | Update repository of op-> | Ja | (r ) Ja | Ja | http://download.opensuse.org/update/leap/15.3/backports/ 5 | repo-debug | Debug Repository | Nein | ---- | ---- | http://download.opensuse.org/debug/distribution/leap/15.3/repo/oss/ 6 | repo-debug-non-oss | Debug Repository (Non-O-> | Nein | ---- | ---- | http://download.opensuse.org/debug/distribution/leap/15.3/repo/non-oss/ 7 | repo-debug-update | Update Repository (Debug) | Nein | ---- | ---- | http://download.opensuse.org/debug/update/leap/15.3/oss/ 8 | repo-debug-update-non-oss | Update Repository (Debu-> | Nein | ---- | ---- | http://download.opensuse.org/debug/update/leap/15.3/non-oss/ 9 | repo-non-oss | Non-OSS Repository | Ja | (r ) Ja | Ja | http://download.opensuse.org/distribution/leap/15.3/repo/non-oss/ 10 | repo-oss | Main Repository | Ja | (r ) Ja | Ja | http://download.opensuse.org/distribution/leap/15.3/repo/oss/ 11 | repo-sle-debug-update | Update repository with -> | Nein | ---- | ---- | http://download.opensuse.org/debug/update/leap/15.3/sle/ 12 | repo-sle-update | Update repository with -> | Ja | (r ) Ja | Ja | http://download.opensuse.org/update/leap/15.3/sle/ 13 | repo-source | Source Repository | Nein | ---- | ---- | http://download.opensuse.org/source/distribution/leap/15.3/repo/oss/ 14 | repo-source-non-oss | Source Repository (Non--> | Nein | ---- | ---- | http://download.opensuse.org/source/distribution/leap/15.3/repo/non-oss/ 15 | repo-update | Main Update Repository | Ja | (r ) Ja | Ja | http://download.opensuse.org/update/leap/15.3/oss/ 16 | repo-update-non-oss | Update Repository (Non--> | Ja | (r ) Ja | Ja | http://download.opensuse.org/update/leap/15.3/non-oss/ zypper> se -s kernel-rt S | Name | Type | Version | Arch | Repository ---+-----------------------+------------+---------------------+--------+------------------------------------------------------------- i+ | kernel-rt | Paket | 5.3.18-150300.112.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | kernel-rt | Paket | 5.3.18-8.3.1 | x86_64 | Main Repository | kernel-rt | Quellpaket | 5.3.18-150300.112.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 | kernel-rt-devel | Paket | 5.3.18-150300.112.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 | kernel-rt-devel | Paket | 5.3.18-8.3.1 | x86_64 | Main Repository | kernel-rt-extra | Paket | 5.3.18-8.3.1 | x86_64 | Main Repository | kernel-rt_debug | Paket | 5.3.18-8.3.1 | x86_64 | Main Repository | kernel-rt_debug | Quellpaket | 5.3.18-150300.112.1 | noarch | Update repository with updates from SUSE Linux Enterprise 15 | kernel-rt_debug-devel | Paket | 5.3.18-150300.112.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 | kernel-rt_debug-devel | Paket | 5.3.18-8.3.1 | x86_64 | Main Repository | kernel-rt_debug-extra | Paket | 5.3.18-8.3.1 | x86_64 | Main Repository zypper> se -s ethercat-kmp-rt S | Name | Type | Version | Arch | Repository ---+---------------------------+-------+---------------------------------------------+--------+----------- i+ | ethercat-kmp-rt | Paket | 1.5.2.429.g3079ece_k5.3.18_8.13-lp153.385.3 | x86_64 | etherlab | ethercat-kmp-rt-debuginfo | Paket | 1.5.2.429.g3079ece_k5.3.18_8.13-lp153.385.3 | x86_64 | etherlab We are aware that the past repository path is resolved recursively and thus should pull other paths (like the SLE paths) automatically. But we don't get, where the build containers pull the different kernel versions / library versions from. Can anyone help? Thanks a lot, Florian

1 0