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
Dear list,
On my CentOS_7 builds on build.opensuse.org the
%python3_sitelib/%python3_sitearch macros do not work anymore:
-bash-4.2$ rpmspec -E '%python3_sitelib'
sh: /usr/bin/python3.6: No such file or directory
-bash-4.2$ rpmspec -E '%python3_sitearch'
sh: /usr/bin/python3.6: No such file or directory
The correct binary would be python3.4
In the job history I see that there was a meta change at April 04, 2019
18:58 and the builds failed from this time on, e.g.:
https://build.opensuse.org/packages/python3-psutil/job_history/home:sebix:i…https://build.opensuse.org/packages/python3-imbox/job_history/home:sebix:in…
I guess that this is a configuration error, but I am not sure where (and
by whom) this can be fixed.
Sebastian
Hi,
I'm not sure if I'm right here, please point me to the correct place
when I'm not :)
I tried to find some software on software.opensuse.org - named "jitsi".
I am told that there is no such package. But
<https://software.opensuse.org/package/jitsi> shows some, at least
community packages.
Similarly, a search for "proxy" shows many packages, but not
"proxytunnel". A direct search for "proxytunnel" also tells me that
there is no package. But again,
<https://software.opensuse.org/package/proxytunnel> shows results.
How can these different results be explained? And can the wrong "no
packages" statements please be eliminated somehow?
Werner
--
Not sure this is the correct list, as it might be an OBS problem, but
also might be some wrong-doing on my side ;)
I have a relative simple package installing Collabora online office via
a docker-compose script and creating the neccessary proxying into the
container:
https://build.opensuse.org/package/view_file/server:eGroupWare/egroupware-c…
Package works on CentOS and Debian/Ubuntu, but I can not get it working
on openSUSE/SLES :(
To me it seems the package test at the end of the build tries to install
the package without it dependencies and then obviously fails:
https://build.opensuse.org/package/live_build_log/server:eGroupWare/egroupw…
Thought adding the dependencies additonal as BuildRequirements also does
not fix the problem either.
Is there a way to stop the packaging test to run the post script (which
tries to start docker and apache)?
Or any other ideas to get a package like that build for openSUSE/SLES?
Ralf
--
Ralf Becker
EGroupware GmbH [www.egroupware.org]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 631 31657-0
Hello,
I am building a new package at https://build.opensuse.org/package/show/home:juliogonzalezgil/sumaform and using the tar service (together with obs_scm)
When trying to build locally, the package builds without any kind of issue.
But after sending the package to the server, all I can see is:
> Files could not be expanded: service error: 400 remote error: /usr/lib/obs/service//tar.service No such file or directory less info
> service daemon error:
> 400 remote error: /usr/lib/obs/service//tar.service No such file or directory
I don't really think the tar service is not available, as I am using that very same service at, for example:
https://build.opensuse.org/package/view_file/systemsmanagement:Uyuni:Master…
And it works fine.
Am I doing something wrong? IIRC, I didn't do anything special when I configured the tar service for Uyuni.
--
Julio González Gil
Release Engineer, SUSE Manager and Uyuni
jgonzalez(a)suse.com
Hi!
at osmocom.org, we're a very happy user of the OBS, and we use it extensively
for generating binary packages for a variety of dpkg based distributions.
I recently added Debian unstabel, Debian testing and xUbuntu 19.04 as
"Repositories" to our network:osmocom:nightly and network:osmocom:latest projects.
The builds look fine (with one exception), see
https://build.opensuse.org/project/monitor/network:osmocom:nightly
and
https://build.opensuse.org/project/monitor/network:osmocom:latest
However, the download directories for those package feeds don't work but give
a 404 error, e.g.:
https://download.opensuse.org/repositories/network:/osmocom:/nightly/xUbunt…
At first I thought "ok, the mirrors need some time to sync", but it has been more
than 48 hours since adding the repositories to the projects, while the download
directories are still all resulting in 404 errors.
Hence my question here: Is this intended? Or is it already a known bug?
In the past, I always simply added new distibutions the same way, and downloads
automatically appeared. The "Publish" flags are all enabled.
Thanks + Keep up the good work!
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Is there a variant of /source/<project> that will return either enough
information in XML to filter client-side or pre-filter server-side to achieve
the following.
A list of _real_ source packages which excludes:
- maintenance updates (revisions of the release source package)
- multi-spec self links (Mesa-drivers to Mesa)
- _multibuild entries (?view=info expands them)
I had same filtering working on top of ?view=info which works well enough for
Leap, but does not work well for maintenance projects and SLE (mix of both) as
anticipated.
Hacks like excluding sourceinfo entries with ':' or '.' end up not working (at
least the '.'). Perhaps ':' is sufficient if no packages are allowed (or
exist) with ':' in name. There are packages with '.' the name that are not
maintenance updates (ex. python-jaraco.base which links python-
jaraco.packaging).
The proper way to differentiate a maintenance update package seems to be
<releasename> in the package meta.
<package name="GraphicsMagick.10066" project="openSUSE:Leap:15.0:Update">
...
<releasename>GraphicsMagick</releasename>
</package>
The problem is that information is not available in view=info nor does it seem
searchable via /search/package[/id]. The search route also does not expand
project links which is necessary for SLE.
Even playing with checking the filename element does not work since image (ie.
non-spec) packages and product packages end up with special cases.
In conclusion, even with a rather complex client-side xpath query it is not
possible to get the list of "real packages" without making lots of followup
queries. Is there a proper way to query the list or can such a method be
added?
--
Jimmy
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi
I am trying to build a package for Fedora on openSUSE's OBS. A
required package has a different name on Fedora. So I thought I would
do the following in my spec file:
%if 0%{?fedora_version}
Substitute: sqlite sqlite3
%endif
In fact, I tried the names in the other order (Substitute: sqlite3
sqlite) as well. It makes no difference. OBS always complains that
nothing provides sqlite3 on Fedora 30. It's like the substitute
directive is not happening.
I'm basing this on these docs:
https://en.opensuse.org/openSUSE:Build_Service_prjconf#Substitute
The project is:
https://build.opensuse.org/package/show/home:rogeroberholtzer/proj
Did I get this wrong?
--
Roger Oberholtzer
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi folks,
we are going to have an OBS Community Get Together at the coming
openSUSE Conference.
So if there is any topic you ever wanted to talk with us or you just
want to have a chat with us, just drop by.
We would be happy to have you there.
We will be at:
Where: Second Floor, Room 3
When: Friday, 24th of May, 4:00pm
My apologies for the short notice, but it seems that my first mail got
lost.
Regards
The OBS developers
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hello all,
we're building Add-on CDs using OBS 2.9.4 (via a '_product' pkg), which generally
works fine (Add-on can be registered/installed using 'yast add-on').
Now I'm looking for a way to automatically install a set of RPMs if my Add-on CD is
installed.
IIRC this was possible using yast2-add-on-creator.
I've read through
https://en.opensuse.org/openSUSE:Build_Service_Concept_Product_Definition, but came
up empty.
Searching through /usr/lib/obs/server/BSProductXML.pm and
/usr/lib/obs/server/bs_productconvert I stumbled across <releasepackage> which
apparently means that one can replace the <PRODUCT>-Addon RPM which is normally
installed?
Then the idea would be to have a custom <PRODUCT>-Addon RPM with simply an additional
'Requires:' to pull in the RPMs I want to install automatically.
I started trying around and also looking at
https://build.opensuse.org/package/view_file/openSUSE:Leap:42.3/_product/op…
However, I couldn't get it to work.
So I guess my questions are: Is there a way to do this with Add-on CDs created via
OBS/Kiwi? Is <releasepackage> the way to go, and if so is there any RTFM I could
perform? Or is there even an easier way?
Thanks and regards -- Till
--
PRESENSE Technologies GmbH Sachsenstr. 5, D-20097 HH
Geschäftsführer/Managing Directors AG Hamburg, HRB 107844
Till Dörges, Jürgen Sander USt-IdNr.: DE263765024
Wir sind wieder auf dem BSI IT-Sicherheitskongress
21.-23. Mai 2019 – Bonn
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org