While the prjmeta of CentOS:CentOS-8 on build.opensuse.org had been
adjusted to account for the decommissioning of mirror.centos.org URLs
(replaced by vault), the same has not been done for
CentOS:CentOS-8:Stream. Please consider updating these too.
I would suggest to do a system-wide grep (e.g. /srv/obs/projects/*.xml)
for mirror.centos.org URLs.
We currently use OBS for building and publishing APT packages for the
Apertis project (a Debian derivative distribution).
At the moment we use downstream patches for the publisher
(src/backend/bs_publish) in order to use reprepro instead of
As we're considering implementing a new APT publisher based on aptly,
we'd like to do so in a way that can be upstreamed to OBS so it can
benefit the whole community. This obviously raises several questions as
to how we should proceed, so I'm sending this email as a call for
We're considering the following:
- this new publisher would be implemented in addition to the existing
dpkg-scan* based one and be selectable through global configuration options.
- using aptly opens up possibilities, but it isn't always as
straightforward as a few system() call; we would therefore need to
either ship a helper tool or add a new BSPublisher submodule (the latter
is the preferred option atm)
- aptly can also be used through a REST API, which implies some
asynchronous processing would be preferrable. Is there currently a way
to handle async processing in OBS, or would that require another helper
tool/module, if possible at all?
We're only at the planning and design stage for now, so we would be very
interested in your opinion and comments regarding the above.
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.
> > > 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)
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-
Well, it is expected that the spec file of the reveision deviates from the
actual package. So how can I branch an earlier version?
I'm trying to beef up the packman arm workers with my army of unused
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
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"
Still, it is apparently not acceptable as a worker:
seife@strolchi:~> osc -A pm checkconstraints \
Multimedia yamdi openSUSE_Tumbleweed armv7l
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"
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)?
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman
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: