Hey.
I am trying to use the OSC tools on fedora but keeps getting this error
[tools@steinwurf-124 ~]$ osc help
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/osc/commandline.py", line 8182,
in _load_plugins
mod = imp.load_source(modname, os.path.join(plugin_dir, extfile))
File "/var/lib/osc-plugins/osc-createspec.py", line 3, in <module>
@cmdln.option('--standard', metavar='STANDARD',
NameError: name 'cmdln' is not defined
/var/lib/osc-plugins/osc-createspec.py: name 'cmdln' is not defined
Try 'env OSC_PLUGIN_FAIL_IGNORE=1 osc ...'
I have installed OSC from the x86_64 repo, found here:
http://download.opensuse.org/repositories/openSUSE:/Tools/Fedora_20/
ANy ideas how to fix it?
My python version is python 2.7.5
Best Regards:
Lars
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
As far as I can find, RPMs are always built using the C locale, which
is non-unicode. This breaks a lot of python packages, which use the
locale of the environment, and thus fail when it gets, for example,
utf-8 in a readme file (which is extremely common). Is there any way
to change the locale that rpm builds in to a utf8-based locale?
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hi!
I tried to use a linked project of type linkedbuild="localdep", and I
expect some packages from the base project to become visible in the
linked project and be built there, but nothing happens. Only packages
existing locally in the linked project are visible.
So here is the whole story:
In a private OBS instance I have a couple of bigger projects with deep
dependencies.
One of the "patterns" I saw, is that a package has 2 alternative
implementations.
To just limit the explanation to a small core, let's say package "a"
depends on package "b" (actually it depends on
pkgconfig(some-stuff-provided-by-b), but I think that should not make
a difference.
Now "b" exists in 2 alternative implementations, which cannot co-exist
in the same installation.
So my idea was:
1. Make a "base project", which contains everything except any
implementation of "b". Quite many packages are built inside the
"base project" but of course "a" is not because "b" is missing. (In
reality I have many "a"s in different depths of dependencies, but
again I guess this should not change the basic concepts)
2. Make a linked project of type linkedbuild="localdep"
(http://en.opensuse.org/openSUSE:Build_Service_Concept_project_linking) ,
which contains one implementation of "b"
The project meta is like this:
<project name="linked">
<title>Linked project</title>
<description></description>
<link project="base"/>
<person userid="uwe.geuder" role="maintainer"/>
<person userid="uwe.geuder" role="bugowner"/>
<repository linkedbuild="localdep" name="foo">
<path project="base" repository="foo"/>
<arch>armv8el</arch>
</repository>
</project>
Now "b" is built successfully and thereafter I would expect OBS to
automatically build "a" in the linked project. But simply nothing
happens. What am I missing here?
Admittedly the "documentation" at
http://en.opensuse.org/openSUSE:Build_Service_Concept_project_linking
talks about rebuilding if a dependency changes. In my case that would
be a bit stretched, because I expect the *first* build to happen when
the dependency becomes available. Is it really so strict that the
latter case is not supported at all?
Obviously, after 2. I wanted to do 3., but as long 2. doesn't work it makes
little sense
3. Make another linked project of type linkedbuild="localdep",
which contains another implementation of "b"
The whole idea is to have OBS to determine the minimal set of packages
needing rebuild and have a "natural set" of packages in my "base" project.
I guess the problem can be solved in 2 ways:
I. Split the "base" project into a lower layer not depending on "b" and
a higher level depending on "b". Then the higher layer could have
2 repos, each depending on a different project providing an implementation
of "b"
II. use linkedbuild="all"
Because the project contains quite some packages I have not yet played
with these alternatives, rebuilding will take time. Primarily I would
like to understand what was wrong with my initial plan and can it be
salvaged somehow.
Regards,
Uwe Geuder
Nomovok Ltd.
Tampere, Finland
uwe.gxuder(a)nomovok.com (bot check: humans correct 1 obvious spelling error)
P.S. After rereading the documentation, I started to wonder...
Is the localdep in 'linkedbuild="localdep"' really a keyword or
does it somehow refer to the name in 'name="localdep"' in the same XML
element? I did not call my new repo "localdep", could that make
the whole repo definition wrong?
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
I successfully built my software on OBS for Fedora, OpenSuse and SLE.
Now I would like to build it for centos/rhel as well, but there are
several build dependencies which are not available in the standard
centos/rhel repositories; they are only available through EPEL.
Is there a way to enable external repositories during build, in order
to get some external BuildRequires? EPEL [1] is a repository sponsored
by Redhat and consists of Fedora packages that did not make it into
rhel (yet).
A few years ago, someone asked the same question [2] on this mailing
list, but I am not sure it ever got resolved.
[1] https://fedoraproject.org/wiki/EPEL/FAQ#What_is_EPEL.3F
[2] http://lists.opensuse.org/opensuse-buildservice/2011-11/msg00142.html
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Adrian,
It is not an issue anymore. I am working on something else now. I do
have an issue with that though.
I am trying to build perl-ExtUtils-MakeMaker on centos 6 and am
getting this error. "nothing provides perl(ExtUtils::Installed) needed
by perl-devel". As a result, the build is unresolvable.
Is there anything I can do to resolve this?
Thank you,
Subir Jolly
On Wed, Aug 20, 2014 at 10:41 AM, Subir Jolly <subirjolly(a)gmail.com> wrote:
> Adrian,
>
> It is not an issue anymore. I am working on something else now. I do have an
> issue with that though.
>
> I am trying to build perl-ExtUtils-MakeMaker on centos 6 and am getting this
> error. "nothing provides perl(ExtUtils::Installed) needed by perl-devel". As
> a result, the build is unresolvable.
>
> Is there anything I can do to resolve this?
>
> Thank you,
> Subir Jolly
>
>
>
>
> On Wed, Aug 20, 2014 at 6:59 AM, Adrian Schröter <adrian(a)suse.de> wrote:
>>
>> On Mittwoch, 6. August 2014, 11:52:26 wrote Subir Jolly:
>>
>> > Guys,
>>
>> >
>>
>> > I am trying to build dirty-resolver 1.0 and I am getting this error
>>
>> > message: "nothing provides libxml2.so.2(LIBXML2_2.6.0)(64bit) needed by
>>
>> > bind-libs".
>>
>> >
>>
>> > The project under which dirty-resolver has centos5/6, rhel5/6. But only
>>
>> > centos 6 is having this issue with every package.
>>
>> >
>>
>> > Please tell me what I could do to fix this issue. Whether it's adding a
>>
>> > repo or something?
>>
>>
>>
>> is this still an issue?
>>
>>
>>
>> Can you point me to an example in that case?
>>
>>
>>
>> --
>>
>>
>>
>> Adrian Schroeter
>>
>> email: adrian(a)suse.de
>>
>>
>>
>> SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
>> 21284 (AG Nürnberg)
>>
>> Maxfeldstraße 5
>>
>> 90409 Nürnberg
>>
>> Germany
>>
>>
>>
>>
>>
>>
>
>
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Guys,
I am trying to build dirty-resolver 1.0 and I am getting this error
message: "nothing provides libxml2.so.2(LIBXML2_2.6.0)(64bit) needed by
bind-libs".
The project under which dirty-resolver has centos5/6, rhel5/6. But only
centos 6 is having this issue with every package.
Please tell me what I could do to fix this issue. Whether it's adding a
repo or something?
Thank you,
Subir
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
to try and fix lxc builds for Fedora, I tried to build the spec
locally on my machine.
I used these two commands to build for 64bit-variants of Fedora 19 and 20:
osc build --clean Fedora_19 x86_64
osc build --clean Fedora_20 x86_64
Building for Fedora19 works, but for Fedora20 I get this for every
package dependency
> Trying openSUSE Build Service server for acl (Fedora:20), not found
> at download.opensuse.org.
A misconfiguration on my side? I would say no, as Fedora19 works.
Using 32bit works for Fedora19, but not for 20.
Is there something missing on the OBS? Known issue?
Regards,
Johannes
- --
Programming is like sex: if you make a mistake, you have to support it
for the rest of your life.
(unknown)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/
iEYEARECAAYFAlOe/rwACgkQzi3gQ/xETbJQZQCfbM6cR4h928Ed1xpH9uOiwHvg
oeIAn0xRPRkx6czZ9KUAcFLMWOO7WjBf
=bD0/
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
I'm in the process of upgrading our now ancient 2.3 version of OBS to
2.5.
I successfully upgraded it to OpenSUSE 12.2, and OBS 2.4. At that time,
since LDAP support was removed, I added the following to the _webui_
section:
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthName "OBS"
AuthType Basic
AuthLDAPBindDN XXXX
AuthLDAPBindPassword XXXX
AuthLDAPURL XXXX
RequestHeader set X-username %{AUTHENTICATE_UID}e
RequestHeader set X-email %{AUTHENTICATE_MAIL}e
require valid-user
and turned on
proxy_auth_mode: :on
However, since webui and api are now one, I put that in the updated
obs.conf vhost file which came with 2.5.
Instead, I now get a forever loop of username/password prompt, and this
is in the logs:
[72dcefa6-381f-445f-aae6-01bce85ac3a8] [8595:0.24] Authenticating with
iChain mode: on
[72dcefa6-381f-445f-aae6-01bce85ac3a8] [8595:0.24] Cache read:
_session_id:e5c5abbaba08b8fd41981c4d300aa58b
[72dcefa6-381f-445f-aae6-01bce85ac3a8] [8595:0.24] Dalli::Server#connect
127.0.0.1:11211
[72dcefa6-381f-445f-aae6-01bce85ac3a8] [8595:0.24] --> direct_http url:
#<URI::Generic:0x00000004891f58 URL:/person/mdrobnak>
[72dcefa6-381f-445f-aae6-01bce85ac3a8] [8595:0.26] http_do: method: get
url: https://localhost:443/person/mdrobnak
[72dcefa6-381f-445f-aae6-01bce85ac3a8] [8595:0.26] Completed 401
Unauthorized in 91ms
[72dcefa6-381f-445f-aae6-01bce85ac3a8] [8595:0.37]
ActiveXML::Transport::UnauthorizedError (<!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Authorization Required</title>
</head><body>
<h1>Authorization Required</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<p>Additionally, a 406 Not Acceptable
error was encountered while trying to use an ErrorDocument to handle the
request.</p>
<hr>
<address>Apache/2.2.22 (Linux/SUSE) Server at localhost Port
443</address>
</body></html>
):
I have this in the config:
frontend_host: "localhost"
frontend_port: 443
frontend_protocol: "https"
Any ideas? This setup was working on 2.4, but I don't want to be in the
position of being behind again, so I want to get 2.5 working.
Thanks.
-Matt
PS There was some fun rails stuff during the 2.4->2.5 upgrade..needed to
hit "1" a few times when doing the obs-api upgrade..