openSUSE Build Service January 2022

buildservice@lists.opensuse.org

29 participants
23 discussions

How can I add a new architecture to the local OBS? I mean the architecture that the OBS official does not support at present.

by senlin xia

Hi all， I want to add a new architecture to local obs，but cannot figure out how to do this. After I communicated with an openSUSE employee, his reply was "there is no guidance document, you need to modify the code yourself".

4 months

Arch builds are not synchronized

by Giovanni Santini

Hi all, After a long time I resurrected my Arch repository and started playing with it again. As you can see, I made my packages "happy": https://build.opensuse.org/project/monitor/home:ItachiSan:archlinux If you open some of them, you will see their builds are quite new. However, in the actual repository: https://download.opensuse.org/repositories/home:/ItachiSan:/archlinux/stand… It seems all those files are not updated. I would like them to be updated / rebuilt due to the recent change in the Arch packages signatures (using supported signatures). Is there any way I can "force a refresh"? Or is there any place where I can check that the synchronization happens/ed correctly? Bests, Giovanni Santini IT Engineer

4 months

The new OBS GIT/SCM bridge

by Adrian Schröter

Yes, really yet another obs git integration, but it might be the last one... ***** This is a disruptive change since it would offload really all source management and workflows into any git, gitlab, pagure or github instances. ***** OBS will just following defined git repositories for all the packageing files (like spec, kiwi or Dockerfiles, but also the upstream sources in form of tar balls or scm repositories). Any native OBS mechanics may *NOT* be usable anymore though. As this would affect more or less all development workflows and tooling, we like to get feedback from you. Esp. in the regard how you would use any the functionality. Some stuff to touch =================== mls and me worked on something the last two weeks what we wanted to have since a long time. We consider this version 0.1, meaning some parts are already working via some workarounds in some cases. We may change it incompatible at any time until the next OBS release happened. There are example setups in OBS to demonstrate this. And also hopefully enables us to discuss about possible setups and workflows for future projects. ***** Just to be clear, do *NOT* use this atm for any package which needs to be submitted to any of our active distributions! So defintive not in any official devel project. ***** If you want to test the existing examples you need to use a forked osc. You get it the tooling via the following commands, but be aware that I did not test much (even though I use it now permanent on my workstation): # zypper ar https://download.opensuse.org/repositories/home:/adrianSuSE:/OBSGIT/15.3/ OBSGIT # zypper dup --from OBSGIT This should update osc and the build package. Also the new obs-scm-bridge package gets installed. Afterwards at the absolute the minimum the follow commands should work: # osc co home:adrianSuSE:OBSGIT/git-example-1 # cd home:adrianSuSE:OBSGIT/git-example-1 # osc build What happens here is that the checkout is detecting that this is a scm bridged package. This is currently implemented as temporary hack via the special string in the package meta title element: <title>obs-scm:https://github.com/adrianschroeter/git-example-1</title> This currently defines the git repository which provides the sources. This will go into a sepecial structure later, but since this affects also remote OBS instances we need a longer prepared update for the stable versions before. osc is therefore not downloading any source files on his own but calls the bridge instead. The bridge is doing two things: 1) clone the git repository into the home:adrianSuSE:OBSGIT/git-example-3 directory. You can use any git command there now. You can *NOT* use osc to submit any change! 2) downloading all the assets. Assets are referenced files in the build descriptions. Esp. tar balls should not become part of these git repositories as this would not scale. But also upstream SCM can be refernced here. Please find out more about assets, how they can setup and how verification can be done in our pbuild documentation: http://opensuse.github.io/obs-build/pbuild.html#_remote_assets We have three examples in OBS to demonstrate how packages could get maintained this way: git-example-1 ============= This is one has our packaging specific files in git and is downloading the upstream files, like the tar ball via the asset mechanism. git-example-2 ============= This one is building directly from some git repository. Everyhing needed is part of this single git repository. The spec might got added in a branch controlled by the package maintainer. Updating the source would work via git merge or rebase. git-example-3 ============= This is basically building from 2 independend git repositories. The packaging specific files are in our own git. The upstream sources come from another git repository, specified inside of the spec file. Note: when you do a checkout using osc, you get currently the upstreams source inside of an .obscpio archive. I will change this to get the git repository as clone. Another example? Please try it on your own, all what you need to have is a git repository and set the <title> element in any package meta.... Please note that IBS has not yet deployed this new code, only build.opensuse.org is working atm. On Project Level ================ You can use the same <scmsync> element to specify a git repository in project meta. Any directory there is considered to be a package. Any build configuration parts (what you have in "osc meta prjconf" usually) can be stored in a file called '_config'. We support this in multiple ways: 1) One plain single repository providing everything. You can find a real life example here: https://build.opensuse.org/project/show/home:adrianSuSE:OBSGIT:Project-exam… or the git repo here: https://github.com/geckito/image-RaspBerryPi4-pi-hole As you notice, it is a repositoy from our Geckito project. This means the same project can get build inside of OBS or it can be build entirely independend using the "pbuild" tool. 2) An example which is more likely to suite larger projects, like our distributions is using git submodules. You can find an example here: https://build.opensuse.org/project/show/home:adrianSuSE:OBSGIT:Project-exam… or the git repo here: https://github.com/adrianschroeter/git-project-example-submodules This is just referencing two git repositories from our earlier examples. 3) A possible later option: We may support URLs on project level pointing to github/gitlab/pagure projects. And listing all repositories inside of these to build these. Tell if you think this would be useful. Disadvantage would be the lack of a signed reference to a git repository. The advantage would be that one would not need to deal with git submodules. In general some first documentation of this functionality can not be found here: https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.scm_bridge… -- Adrian Schroeter <adrian(a)suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

4 months

fc35 osc depends on python 3.9

by Stefan van der Eijk

I'm seeing a python abi dependency issue with the osc package in the fc35 repo: $ sudo dnf update Dependencies resolved. Problem: cannot install the best update candidate for package osc-0.175.0-321.4.noarch - nothing provides python(abi) = 3.9 needed by osc-0.175.0-321.5.noarch - nothing provides python3.9dist(chardet) needed by osc-0.175.0-321.5.noarch - nothing provides python3.9dist(m2crypto) needed by osc-0.175.0-321.5.noarch ============================================================================================================================================================================================================================================================================================================================= Package Architecture Version Repository Size ============================================================================================================================================================================================================================================================================================================================= Skipping packages with broken dependencies: osc noarch 0.175.0-321.5 openSUSE_Tools 479 k Transaction Summary ============================================================================================================================================================================================================================================================================================================================= Skip 1 Package Nothing to do. Complete! FC35 comes with Python 3.10 installed: $ python --version Python 3.10.0 A previous package (still installed) did depend on the correct python version. This is the Requires difference between previous (osc-0.175.0-321.4.noarch, installed on my system) and current (osc-0.175.0-321.5.noarch, on the repo) package: $ diff <(rpm -qR osc | sort) <(rpm -qpR osc-0.175.0-321.5.noarch.rpm |sort) -U0 --- /dev/fd/63 2021-12-16 10:45:21.493561420 +0100 +++ /dev/fd/62 2021-12-16 10:45:21.494561419 +0100 @@ -1,3 +1,3 @@ -config(osc) = 0.175.0-321.4 -python3.10dist(chardet) -python3.10dist(m2crypto) +config(osc) = 0.175.0-321.5 +python3.9dist(chardet) +python3.9dist(m2crypto) @@ -6 +6 @@ -python(abi) = 3.10 +python(abi) = 3.9

4 months

Leap builds - another inconsistency for python-builds

by Axel Braun

Hi, I have one package (python-pydyf) in d:l:p and in two other repos with basically the same prjconf. In one it builds, in another one its broken for 15.3, but still builds locally! In this case it fails in testing: Direct construction of IsortItem has been deprecated, please use IsortItem.from_parent. ...although pyproject.toml is patched: [tool.pytest.ini_options] addopts = '--isort --flake8 --cov --no-cov-on-fail' beside this case, I would be interested why a package build locally but sometimes on OBS, sometimes not.... Any ideas? Thanks! Axel

4 months, 1 week

Qemu startup options

by Marcus Schäfer

Hi, I'm currently trying to understand how parameters are used to call the obs worker virtual machine. If I run a local build via "osc build --vm-type kvm ..." the parameters are set by the code from the build package and script in: /usr/lib/build/build-vm-kvm If the build is done by the obs server backend it looks different and I thought how are the parameters defined when running your own OBS server ? Can someone point me to the right direction ? Thanks Regards, Marcus -- Public Key available via: https://keybase.io/marcus_schaefer/key.asc keybase search marcus_schaefer ------------------------------------------------------- Marcus Schäfer Am Unterösch 9 Tel: +49 7562 905437 D-88316 Isny / Rohrdorf Germany -------------------------------------------------------

4 months, 1 week

broken devel packages

by Manfred Schwarb

Hi, lately, a lot of devel packages are broken, e.g. https://build.opensuse.org/package/show/network:dhcp/dhcp https://build.opensuse.org/package/show/Application:Geo/python-OWSLib etc. etc. They show messages "Files could not be expanded: could not apply patch 'project.diff'" or similar. If one wants to branch such a package, an internal OBS error occurs (sic!). So how is one supposed to branch such a package? To bug the maintainers of each package individually? Can't this solved in a more general, automated way? Thanks, Manfred

4 months, 1 week

Fedora 35 repo rpc timeout

by Srivats P

Hi, On my private OBS instance connected to the public one on build.opensuse.org/public, Fedora 35 repo shows an error - The repository setup is broken, build or publish is not possible In the x86 scheduler log I see the following rpc timeout error - fetching remote repository state for openSUSE.org:Fedora:35/standard rpc timeout repository 'openSUSE.org:Fedora:35/standard' is unavailable Adding/removing or enabling/disabling the repo doesn't help. Any suggestions? Srivats

4 months, 1 week

Building an NPM (or electron?) package (in my case https://github.com/kubernetes-sigs/kui)

by Johannes Kastl

Hi all, I tried the wiki and some search-foo but ended up with deprecated things on how to build a NPM package (or something that looks like it). https://en.opensuse.org/openSUSE:Packaging_nodejs In my case I wanted to try building kui from https://github.com/kubernetes-sigs/kui, which to me looks like NPM-Foo: Quoting the README: > I don't trust the prebuilts > > We hear you. Choose your platform (e.g. mac:amd64), execute the following, then look in ./dist/electron. > > git clone git@github.com:kubernetes-sigs/kui.git && cd kui && npm ci && \ > npm run build:electron:mac:amd64 Might not be the best package to get going with NPM, as it seems rather complex. So any hints are highly appreciated. Kind Regards 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

4 months, 2 weeks

"Stuck" dependencies in RockyLinux:8 repository?

by Georg Brandl

Hi all, I'm having problems with building a package for RockyLinux:8. It seems to be stuck on old Qt 5.12 libraries, while 5.15 is the current version in the upstream repositories. The package is here: https://build.opensuse.org/package/show/home:gbrandl/python3-qt5-qtwebengine With AlmaLinux:8, which should have basically the same repository contents, resolving works fine. The Rocky repo metadata is: <repository name="Rocky"> <path project="Fedora:EPEL:8" repository="standard"/> <path project="RockyLinux:8" repository="standard"/> <arch>x86_64</arch> </repository> and the resolver error is: unresolvable: nothing provides libQt5Core.so.5(Qt_5.15)(64bit) needed by qt5-qtwebengine, nothing provides libQt5QmlModels.so.5()(64bit) needed by qt5-qtwebengine, nothing provides libQt5Core.so.5(Qt_5.15.2_PRIVATE_API)(64bit) needed by qt5-qtwebengine, nothing provides libQt5Gui.so.5(Qt_5.15.2_PRIVATE_API)(64bit) needed by qt5-qtwebengine, nothing provides libQt5Quick.so.5(Qt_5.15.2_PRIVATE_API)(64bit) needed by qt5-qtwebengine, nothing provides libQt5Widgets.so.5(Qt_5.15.2_PRIVATE_API)(64bit) needed by qt5-qtwebengine, nothing provides qt5-qtbase(x86-64) = 5.15.2 needed by qt5-qtwebengine, (got version 5.12.5-8.el8.2 provided by qt5-qtbase) best regards, Georg -- Jülich Centre for Neutron Science JCNS at Heinz Maier-Leibnitz Zentrum MLZ Forschungszentrum Jülich GmbH Lichtenbergstraße 1 85747 Garching GERMANY Telefon: +49 - 89 158860 731 Telefax: +49 - 89 158860 799 --------------------------------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Frauke Melchior ---------------------------------------------------------------------------------------------

4 months, 2 weeks

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Build Service January 2022