Hello,
My OpenSuse RPM repositories on that mirror are not in sync with
Opensuse. Could you please help me? I get tons of "Checksum mismatch"
errors if I try to work with it. Unfortunately
https://build.opensuse.org gives me a HTTP redirect to the broken mirror.
All of my repositories on
http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories…
are not in sync and outdated. Can you fix this please? Or can you least
remove this broken mirror from the Opensuse mirror list (http redirect)
if reparation is not possible?
Please let me know, thanks in advance!
Best regards
Winfried
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi,
I branched the graphics:vkd3d package in order to work on getting it to build on Leap 15.0. My x86_64 build succeeds, but the i586 repository shows "excluded," so the baselibs aren't building.
Any idea why this is happening and how I can fix it?
--
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
Two questions:
- Is it possible to have a container rebuild whenever the underlying packages
are updated (ie. any package included in the container) even if the packages
are in underlying repo path elements and not the project with the container?
- Is it possible to publish multiple tags to the opensues registry? Using
additionaltags on containerconfig element in kiwi file they are supposedly
set, but only tag ends up in the registry.
- Related is it possible to keep older revisions (a couple) or "pin" certain
tags and keep those until unpinned? Having only a single version of a
container is not ideal as it makes it impossible to roll-back to previous
version.
Project in question: home:jberry:container/osrt-worker-obs.
As a note the prjconf necessary to build containers is not terribly visible,
intuitive, or documented.
--
Jimmy
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hello,
I am running private OBS instance and all i586 builds for Factory are
failed with the following log:
package build was not possible:
no compliant workers (constraints mismatch hint: hardware:cpu)
Please adapt your constraints.
At the same time, there is no constraints in the packages. I have x86_64
workers, and other distros are fine. How could I fix it?
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Julio González Gil wrote:
> On viernes, 7 de septiembre de 2018 14:41:54 (CEST) Ludwig Nussel wrote:
>> Julio González Gil wrote:
>>> We basically want to release each two/four/six weeks a new version,
>>> starting with 4.0, promoting packages from systemsmanagement:Uyuni:Master
>>> (development project) to some place.
>>
>> Check the :ToTest mechanism of Factory.
>
> I think this is exactly what I could need!
>
> However I see at https://build.opensuse.org/project/show/
> openSUSE:Factory:ToTest that the project is described as "This project does
> not build, it is just for storing snapshots used for automated testing. The
> result is released as Tumbleweed" but https://build.opensuse.org/package/
> view_file/openSUSE:Factory:ToTest/000product/
> _service:product_converter:openSUSE-ftp-ftp-i586_x86_64.kiwi?expand=1 seems to
> be publishing to <productoption name="REPO_LOCATION">http://
> download.opensuse.org/tumbleweed/repo/oss/</productoption>
It's not relevant what is in that file. The point about the mechanism is
that the main project can be used for building and only if it's done
building the packages are moved over to :ToTest for testing by
openQA. Based on that the result is released or held back.
>>> Between one version and the other, there will be no maintenance. Each
>>> change, whatever itis, will required a new release and version.
>>>
>>> You could see it as Tumbleweed to some extent, but with a big difference:
>>> we really want to have versions, as Leap or SLE, but unlike Leap or SLE,
>>> very frequent releases.
>>
>> Tumbleweed does have an integer number as version that can be
>> displayed as date. Just not coded into the project name in OBS. By
>> default OBS only publishes the last version of the repo to
>> download.o.o. There is work in progress to keep some previous
>> snapshots around though:
>> http://release-tools.opensuse.org/2018/02/26/Tumbleweed-snapshot-review-site
>> .html
>
> Yes, I had a look at https://github.com/boombatower/tumbleweed-cli/blob/
> master/tumbleweed which is mentioned at one of the links of your link above,
> but as you said, the snapshots are not ready yet.
>
> Since you mentioned that "by default OBS only the last version of the repo to
> download.o.o", is there a switch I can change at the prjconfig, meta or
> _product to change that behaviour?
No, we have scripts on download.opensuse.org side that implement the
history outside OBS. Nevertheless if that is a more often requested
feature, maybe the OBS team wants to implement it after all ... :-)
What I wanted to say is that instead of jumping through hoops
creating subprojects etc (where users would have to change their repos),
just stick with the one project approach. If historic repo versions turn
out to be really needed, OBS should implement means for that.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hello List,
I'm trying to build the cfengine package for Ubuntu. I've followed the
tutorial/howto from the Wiki, and things worked out as far as starting
the build process proper. However, I've been unable to provide a
certain requirement. I've edited debian.control to contain this line:
Build-Depends: debhelper (>= 8.0.0), liblmdb-dev
Now, the build terminates early because the dependency on liblmdb-dev
is unmet. For RPM builds, merely stating the dependency is enough to
draw in the necessary package (if it's in the correct repo), so I
assumed the problem lies in the fact that lmdb is a "Universe"
package (I assume this means it's not in the standard repo, but
somewhere else). So I've used a _service file to recompile lmdb in the
same OBS project I'm using for my package-to-be, but to no avail: OBS
still complains about
[ 11s] dpkg-checkbuilddeps: error: Unmet build dependencies: liblmdb-dev
What am I doing wrong?
Thanks,
A.
--
Ansgar Esztermann
Sysadmin
http://www.mpibpc.mpg.de/grubmueller/esztermann
Hi,
All my Arch builds are failing, or more accurately not even getting
started, due to the error:
[ 24s] querying package ids...
[ 26s] [1/253] installing archlinux-keyring-20180808-1
[ 26s] pacman: error while loading shared libraries: libzstd.so.1:
cannot open shared object file: No such file or directory
[ 26s] exit ...
here is an example full log:
https://gist.github.com/5e2ce92a8412753869e09f4297278480. Guessing
this is an upstream issue that will be fixed with the next Arch
snapshot you's
take.
Thanks for your time,
Brenton
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi all,
today we stumbled upon a snag in osc copypac. The task was to copy a
package, that is a link with a link diff, to another project within the
same (private) buildservice instance. In our case the link was to a
package on the openSUSE buildservice.
We found that using "osc copypac -e" works as expected, the resulting
package is no longer a link.
We also found that using no options (no -e, no -K) copies the link, i.e.
the new package is still a link with a link diff, pointing to the
original target.
But we found that using -K, which is also called --keep-link, does not
keep the link. Instead we had the same result as when calling osc
copypac with -e.
Unfortunately, the man page is pretty confusing here.
-K, --keep-link keep the source link in target, this also expands
the source
But this is also not consistent, we got the same state three times while
copying another package, i.e. copying with "-e", "-K" or without options
resulted in a package that was no link anymore. We found no consistent
explanation for that behaviour.
I'll try to set up a reproducible example on the openSUSE build service
tomorrow.
In the meantime, can someone please explain what "-K" aka "--keep-link"
is supposed to do?
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
Hi everyone,
In this case we are talking about Uyuni (systemsmanagement:Uyuni), the new
upstream for SUSE Manager (replacing spacewalk).
We basically want to release each two/four/six weeks a new version, starting
with 4.0, promoting packages from systemsmanagement:Uyuni:Master (development
project) to some place.
Between one version and the other, there will be no maintenance. Each change,
whatever itis, will required a new release and version.
You could see it as Tumbleweed to some extent, but with a big difference: we
really want to have versions, as Leap or SLE, but unlike Leap or SLE, very
frequent releases.
This is useful, for example, if users are running a version of Uyuni in
"production", we release a new version, and they want to setup a server with
the same version as "production" and then test migration.
One way I see to do this would be creating a systemmanagement:Uyuni subproject
for each version and then freeze the packages (so we would have
systemsmanagement:Uyuni:4.0, systemsmanagement:Uyuni:4.1,
systemsmanagement:Uyuni:4.2 and so on...)
However I wonder if this is the correct way to do it, because to me it seems a
little bit overkill.
Other option, of course, would be just storing the zypper repositories outside
OBS/download.opensuse.org (there would be a set of repositories for each
version), but I don't like the idea.
I was reviewing how other products are working, but could not find any that
uses this approach. Basically either they have versions with maintenance
(:Update subproject), either they follow Tumbleweed approach, where the
product itself is not versioned.
So, has anyone in the list experience about how to achieve this with OBS?
Thanks!
--
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)
Hey,
On 06.09.2018 17:22, Julio González Gil wrote:
> I am not even sure if OBS administrators would be happy if we generate 24
> projects (or even more per year).
https://build.opensuse.org/ -> openSUSE Build Service hosts 55,739
projects... :-)
Henne
--
Henne Vogelsang
http://www.opensuse.org
Everybody has a plan, until they get hit.
- Mike Tyson
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org