openSUSE Build Service October 2018

buildservice@lists.opensuse.org

19 participants
14 discussions

[opensuse-buildservice] Public Key not available SLE_12_SP3 s390x
by Usman Haider 27 Nov '19

27 Nov '19

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

4 9

[opensuse-buildservice] OBS Appliance - Unable to Update
by Khalil Graves 15 Apr '19

15 Apr '19

I am running OBS Appliance 2.8.2 on VMware ESX. When the appliance boots I get an error "Failed to start LSB: Finds the storage device to be used for OBS server and/or worker." I have included a dump of systemctl status obsstoagesetup.service below. I Just want to confirm if this is normal or should be addressed. I also attempted and update of a clone of my appliance via zypper but 2 GB root drive is not sufficient for upgrades. Update begins but end with "Error Code: Write Error". I checked root drive and it was up to 100% utilization from 93% prior to update. I decided to install latest version of OBS appliance over existing install. New appliance adopts my old setting but now I am getting and error on boot "Failed to start LSB: open build service source service server." In addition I am unable to build rpms in this current state. Not sure what to do next to get the cloned appliance to build a package. SYSTEMCTL status obsstoragesetup.service obsstoragesetup.service - LSB: Finds the storage device to be used for OBS server and/or worker Loaded: loaded (/etc/init.d/obsstoragesetup; bad; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2018-03-06 18:44:59 UTC; 16min ago Docs: man:systemd-sysv-generator(8) Process: 1365 ExecStart=/etc/init.d/obsstoragesetup start (code=exited, status=1/FAILURE) Mar 06 18:44:59 linux obsstoragesetup[1365]: OBS_SERVER_SIZE=38912 Mar 06 18:44:59 linux obsstoragesetup[1365]: TOTAL_SWAP_SIZE=1024 Mar 06 18:44:59 linux obsstoragesetup[1365]: FINAL_VG_SIZE = 12284 - 38912 - 25600 - 1024 Mar 06 18:44:59 linux obsstoragesetup[1365]: FINAL_VG_SIZE=-53252 Mar 06 18:44:59 linux obsstoragesetup[1365]: OBS_WORKER_ROOT_SIZE=-26626 Mar 06 18:44:59 linux obsstoragesetup[1365]: MIN_WORKER_ROOT_SIZE=4096 Mar 06 18:44:59 linux systemd[1]: obsstoragesetup.service: Control process exited, code=exited status=1 Mar 06 18:44:59 linux systemd[1]: Failed to start LSB: Finds the storage device to be used for OBS server and/or worker. Mar 06 18:44:59 linux systemd[1]: obsstoragesetup.service: Unit entered failed state. Mar 06 18:44:59 linux systemd[1]: obsstoragesetup.service: Failed with result 'exit-code'. SYSTEMCTL status obsservice.service obsservice.service - LSB: open build service source service server Loaded: loaded (/etc/init.d/obsservice; bad; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2018-03-09 11:59:39 UTC; 3min 34s ago Docs: man:systemd-sysv-generator(8) Process: 1761 ExecStart=/etc/init.d/obsservice start (code=exited, status=7) Mar 09 11:59:38 linux systemd[1]: Starting LSB: open build service source service server... Mar 09 11:59:39 linux startproc[1788]: startproc: exit status of parent of /usr/lib/obs/server/bs_service: 13 Mar 09 11:59:39 linux obsservice[1761]: Initializing obsservice..failed Mar 09 11:59:39 linux systemd[1]: obsservice.service: Control process exited, code=exited status=7 Mar 09 11:59:39 linux systemd[1]: Failed to start LSB: open build service source service server. Mar 09 11:59:39 linux systemd[1]: obsservice.service: Unit entered failed state. Mar 09 11:59:39 linux systemd[1]: obsservice.service: Failed with result 'exit-code'. '. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 4

[opensuse-buildservice] OBS + GitHub - deprecation of GitHub Services
by Linux Kamarada 19 Mar '19

19 Mar '19

Hello, guys! I searched how to integrate OBS with GitHub so that a git push would cause OBS to fetch the source code and build. I followed directions on these pages: https://openbuildservice.org/2013/11/22/source-update-via_token/ https://github.com/seccubus/obs_autobuild_test (CC their authors, thank you for the great material!) But when I opened GitHub's Integration & services to add the Obs service, I read this: "Note: [GitHub Services are being deprecated][1]. Please contact your integrator for more information on how to migrate or replace a service with [webhooks][2] or [GitHub Apps][3]." [1]: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ [2]: https://developer.github.com/webhooks/ [3]: https://developer.github.com/apps/differences-between-apps/#about-github-ap… The news is from April 25, 2018. The first paragraph summarizes it: "GitHub plans on shutting down GitHub Services so we can shift focus to other areas of the API, such as strengthening GitHub Apps and GraphQL, and improving webhooks. The intention of GitHub Services was to allow third-party developers to submit code for integrating with their services, but this functionality has been superseded by GitHub Apps and webhooks. GitHub Services has not supported new features since April 25, 2016, and we plan to officially deprecate it on October 1st, 2018." Although I successfully integrated OBS with GitHub using a GitHub Service, is it already possible to do that same integration using GitHub Apps or webhooks? Thank you! Antonio The Linux Kamarada Project http://kamarada.github.io/ -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

7 12

[opensuse-buildservice] Phantom binaries in openSUSE:Factory:PowerPC/standard/ppc/_repository
by Andreas Schwab 13 Dec '18

13 Dec '18

The repository in openSUSE:Factory:PowerPC/standard/ppc contains a lot of binaries that are not originating from any package build. Especially the python{2,3}-pluggy.rpm binaries are obnoxious because they are overriding the ones built from the python-pluggy package. $ osc api build/openSUSE:Factory:PowerPC/standard/ppc/_repository | grep python.-pluggy <binary filename="python2-pluggy.rpm" size="31706" mtime="1513504048" /> <binary filename="python3-pluggy.rpm" size="31974" mtime="1513504048" /> $ osc api build/openSUSE:Factory:PowerPC/standard/ppc/python-pluggy | grep python.-pluggy <binary filename="python2-pluggy-0.7.1-1.1.noarch.rpm" size="38904" mtime="1538147591" /> <binary filename="python3-pluggy-0.7.1-1.1.noarch.rpm" size="39604" mtime="1538147591" /> When I disable useforbuild in the python-pluggy package the phantom binaries disapper, and reenabling useforbuild brings the correct binaries into the repository. But after some time the phantom binaries reappear. Other than that there are about 150 phantom binaries in the repository. Andreas. -- Andreas Schwab, SUSE Labs, schwab(a)suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

1 1

[opensuse-buildservice] Caching interconnect requests for when interconnect is down?
by Neal Gompa 07 Nov '18

07 Nov '18

Hey, Is there a way to make it so that build service instances that interconnect to api.opensuse.org cache the configurations so that in the event the server is down, builds can keep going, using cached configurations and binary packages that cached locally on the build service? I'd like to avoid issues similar to what happened earlier in the year and last year when the API was down and caused `osc build` runs to fail, as well as builds on the build service instance itself to fail due to inability to get configurations from the API, while still maintaining the interconnect because I don't want to fork all the build configurations and content and import them into my instance. If that's not possible for OBS 2.9, what can we do to make this work for OBS 2.10? -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 4

[opensuse-buildservice] 504 gateway timeout
by Rosanne DiMesio 28 Oct '18

28 Oct '18

I'm getting a 504 gateway timeout when trying to log into the OBS via the web interface. -- 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

2 1

[opensuse-buildservice] Server returned an error: HTTP Error 401: Unauthorized
by Brenton Horne 28 Oct '18

28 Oct '18

Hi, I'm getting the error: "Server returned an error: HTTP Error 401: Unauthorized" whenever I run: osc ci -m "Bumping to 8.1.0488" (as I'm trying to bump my Vim packages). I am getting this error from Arch Linux. I have chrooted into my other distros (openSUSE Tumblewleed and Gentoo) and tried running this command too and I get the same error. I have checked my credentials in ~/.oscrc and they're correct. I've tried logging into the OBS web interface using them without a problem. Anyone know how to fix this? Thanks for your help and patience, Brenton -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 3

[opensuse-buildservice] openSUSE:Tools is failing GPG check (CentOS 7)
by Neal Gompa 24 Oct '18

24 Oct '18

Hey, I tried to install some packages from the openSUSE:Tools project for CentOS 7, and it failed to validate with the GPG key that is provided in the .repo file with one of the packages. This is the error: Retrieving key from http://download.opensuse.org/repositories/openSUSE:/Tools/CentOS_7/repodata… Importing GPG key 0x013E5B65: Userid : "openSUSE:Tools OBS Project <openSUSE:Tools@build.opensuse.org>" Fingerprint: fcad afc8 1273 b9e7 f184 f2b0 8266 59a9 013e 5b65 From : http://download.opensuse.org/repositories/openSUSE:/Tools/CentOS_7/repodata… warning: /var/cache/yum/x86_64/7/openSUSE_Tools/packages/obs-service-set_version-0.5.9-91.1.noarch.rpm: Header V3 DSA/SHA1 Signature, key ID eefefde9: NOKEY Retrieving key from http://download.opensuse.org/repositories/openSUSE:/Tools/CentOS_7/repodata… The GPG keys listed for the "openSUSE.org tools (CentOS_7)" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository. Failing package is: obs-service-set_version-0.5.9-91.1.noarch GPG Keys are configured as: http://download.opensuse.org/repositories/openSUSE:/Tools/CentOS_7/repodata… I think the repository needs to be fully re-signed with the key, since it was rotated... I've attached the full log to the email. -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

[opensuse-buildservice] SLE: Dependencies failed despite packages are available at repositories at Meta
by Julio González Gil 24 Oct '18

24 Oct '18

This must be something stupid, but I can't see what I am doing wrong. I am trying to build Uyuni Client Tools at: https://build.opensuse.org/ project/show/systemsmanagement:Uyuni:Master:SLE12-Uyuni-Client-Tools One of the packages (that is able to build internally at build.opensuse.de) fails to build is spacewalk-backend https://build.opensuse.org/package/show/ systemsmanagement:Uyuni:Master:SLE12-Uyuni-Client-Tools/spacewalk-backend Message is: nothing provides python-debian, nothing provides yum But I cannot understand why, because at Meta I have SUSE:SLE-12:Update/ standard: https://build.opensuse.org/project/meta/ systemsmanagement:Uyuni:Master:SLE12-Uyuni-Client-Tools And even SUSE:SLE-12:GA, and both are exactly the same projects I use internally And packages seems to be there: https://build.opensuse.org/package/show/SUSE:SLE-12:Update/yum https://build.opensuse.org/package/show/SUSE:SLE-12:Update/python-debian I tried <path project="SUSE:SLE-12-SP3:Update" repository="standard"/> <path project="SUSE:SLE-12-SP3:GA" repository="standard"/> But no difference. To some extent, something similar seems to be happening with: https:// build.opensuse.org/package/show/systemsmanagement:Uyuni:Master:SLE15-Uyuni- Client-Tools/spacewalk-backend as it can't find python-yum for SLE15, while internally it works fine. What am I doing wrong? -- Julio González Gil <jgonzalez(a)suse.com> Release 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)

2 4

[opensuse-buildservice] increase release numbers on copypac
by Morschhäuser, Mark 18 Oct '18

18 Oct '18

Hi, I want to copypac a whole project into another one and want to ensure that the generated rpm packages have at least the same, if not higher release numbers than the latest build of each package. (I want to prevent OBS from using the entry from the spec file). Do I need to set the OBS:MakeOriginOlder Attribute in the destination project? Best Regards, Mark -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Build Service October 2018