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".
After a long time I resurrected my Arch repository and started playing with it again.
As you can see, I made my packages "happy":
If you open some of them, you will see their builds are quite new.
However, in the actual repository:
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?
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
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:
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:
We have three examples in OBS to demonstrate how packages could get maintained this way:
This is one has our packaging specific files in git and is downloading the upstream files,
like the tar ball via the asset mechanism.
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.
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
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
or the git repo here:
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:
or the git repo here:
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:
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
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
...although pyproject.toml is patched:
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....
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:
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 ?
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
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
repository 'openSUSE.org:Fedora:35/standard' is unavailable
Adding/removing or enabling/disabling the repo doesn't help.
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).
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 firstname.lastname@example.org: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.
Linux Consultant & Trainer
Tel.: +49 (0) 151 2372 5802
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg
GF: Ralph Dehner
Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
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:
With AlmaLinux:8, which should have basically the same repository contents,
resolving works fine.
The Rocky repo metadata is:
<path project="Fedora:EPEL:8" repository="standard"/>
<path project="RockyLinux:8" repository="standard"/>
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)
Jülich Centre for Neutron Science JCNS
at Heinz Maier-Leibnitz Zentrum MLZ
Forschungszentrum Jülich GmbH
Telefon: +49 - 89 158860 731
Telefax: +49 - 89 158860 799
Forschungszentrum Juelich GmbH
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.