Hello,
why is this done?
-----------------------------------------------------------------
I have the following modifications for test.spec:
24c24
< Requires: bash ksplashx >= 4.2 mc kwin >= 4.1
---
> Requires: bash mc kdebase4-workspace kde4-kwin
-----------------------------------------------------------------
Prjconf has:
Substitute: ksplashx kdebase4-workspace
Substitute: kwin kde4-kwin
It clearly knows about the versions, but it strips them away for whatever
reason, which I don't understand, since if I want at least a certain version
of something, I don't really care what the exact name of the package is.
--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: l.lunak(a)suse.cz , l.lunak(a)kde.org
Lihovarska 1060/12 tel: +420 284 028 972
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hello,
I'm trying to build a package for also other distributions and I have a
problem with Mandriva. The package is home:llunak:kde/taskbarswitch, just a
very simple KDE app. The build repository is 'Mandriva 2009', as offered by
one of the buttons in the 'Add Repository' page.
First the simpler (second :) ) problem. After I actually manage to
successfully build the package, I cannot install it on my testing Mandriva
installation. When trying to install it, urpmi complains that there is no
liblzma.so.0, which is required by the package. I eventually figured out that
my Mandriva install is Mandriva 2009.1 AKA 2009 Spring, while buildservice
builds only for Mandriva 2009.0.
Will it be (and when) possible to use 2009.1 with buildservice? It is the
latest Mandriva release and the only release offered for download at
http://mandriva.com.
Now the first problem. When I just added the Mandriva 2009 build repository
and tried to build the package, with BuildRequires being only libkde4-devel,
mapped to kdelibs4-devel for Mandriva using Substite in 'osc meta prjconf
home:llunak:kde', running 'osc build Mandriva_2009 x86_64 taskbarswitch.spec'
said:
buildinfo is broken... it says:
expansion error: have choice for kde4-config-file needed by lib64kdecore5:
free-kde4-config flash-kde4-config one-kde4-config powerpack-kde4-config,
have choice for kde4-l10n needed by lib64kdecore5: kde4-l10n-el kde4-l10n-uk
kde4-l10n-lt kde4-l10n-be kde4-l10n-fr kde4-l10n-de kde4-l10n-eo kde4-l10n-km
kde4-l10n-ar kde4-l10n-mk kde4-l10n-pt_BR kde4-l10n-wa kde4-l10n-eu
kde4-l10n-sv kde4-l10n-ta kde4-l10n-ku kde4-l10n-hi kde4-l10n-it kde4-l10n-et
kde4-l10n-fi kde4-l10n-ga kde4-l10n-ja kde4-l10n-pl kde4-l10n-cs kde4-l10n-fy
kde4-l10n-th kde4-l10n-fa kde4-l10n-tr kde4-l10n-zh_TW kde4-l10n-es
kde4-l10n-ca kde4-l10n-se kde4-l10n-zh_CN kde4-l10n-nl kde4-l10n-is
kde4-l10n-nb kde4-l10n-ru kde4-l10n-da kde4-l10n-gl kde4-l10n-lv kde4-l10n-ko
kde4-l10n-nds kde4-l10n-ml kde4-l10n-csb kde4-l10n-kk kde4-l10n-en_GB
kde4-l10n-pt kde4-l10n-bg kde4-l10n-ne kde4-l10n-ro kde4-l10n-sl kde4-l10n-pa
kde4-l10n-hu kde4-l10n-nn kde4-l10n-sr, have choice for phonon-backend >=
4.2.0 needed by lib64kdecore5: phonon-xine phonon-gstreamer
So I ended up adding (interestingly there is only en_GB, no en_US, I wonder
what Mandriva installs on default installs):
Prefer: phonon-gstreamer free-kde4-config kde4-l10n-en_GB
Then it said:
buildinfo is broken... it says:
expansion error: have choice for mandriva-theme needed by free-kde4-config:
mandriva-theme-Flash mandriva-theme-Free mandriva-theme-One
mandriva-theme-Powerpack, have choice for mandriva-theme-screensaver needed
by mandriva-kde4-config-common: mandriva-theme-One-screensaver
mandriva-theme-Powerpack-screensaver mandriva-theme-Free-screensaver
mandriva-theme-Flash-screensaver
So prefers is extended to:
Prefer: free-kde4-config mandriva-theme-Free mandriva-theme-Free-screensaver
Prefer: phonon-gstreamer kde4-l10n-en_GB
There are still problems:
buildinfo is broken... it says:
expansion error: have choice for kernel needed by bootsplash:
kernel-desktop-2.6.27-0.rc8.2mnb kernel-server-2.6.27-0.rc8.2mnb
kernel-xen-2.6.18.8-xen-3.3.0-2mdv, have choice for webfetch needed by urpmi:
wget curl
Which leads to the project config requiring all this to make the package
build:
Prefer: free-kde4-config mandriva-theme-Free mandriva-theme-Free-screensaver
Prefer: phonon-gstreamer kde4-l10n-en_GB
Prefer: curl kernel-desktop-2.6.27-0.rc8.2mnb
Would it be possible to somehow fix this for the Mandriva 2009 build
repository instead of repositories having to work this around? It's rather
confusing that it doesn't work out of the box, and the choices are either
obvious and don't really matter anyway.
Thanks
--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: l.lunak(a)suse.cz , l.lunak(a)kde.org
Lihovarska 1060/12 tel: +420 284 084 672
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
"Dominique Leuenberger" <Dominique.Leuenberger(a)TMF-Group.com> writes:
>>>> On 6/25/2009 at 14:37, "Dominique Leuenberger"
> <Dominique.Leuenberger(a)TMF-Group.com> wrote:
>> I'm running an OBS and as such could just link to the source project which
>> is maintained by Stefan. It would merely be to have the binareis hosted
>> 'off' the opensuse.org domain.
>> If we can arrange for some DNS entries on opensuse-community.org for example,
>> this would not cause a problem at all for me (my data transfer limit is
>> 50GB/month at the moment of which I hardly use 1GB now).
>
> I went down the ally and tried to link the sources from
> X11:Drivers:Video to my local OBS. Not surprisingly of course, this
> does not (yet) work, as the 'real' blob is missing in the Source repo
> on OBS (The user is supposed to download it before the build
> command). (I tried nvidia only... simply because I have those cards in
> all my systems and it would allow me to test the resulting RPMs).
>
> Stefan, any good ideas on how we can achieve this to be 'more
> automatic' than it is now?
I think obs downloading pristine tar balls would be a Good Thing (TM)
anyway, for various reasons, the most prominent being that it makes
source file tampering harder: with this, an evil contributor needed to
fake the original tar ball. So this feature also takes burden from the
package maintainers.
http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-SOURCE-TAG
> Maybe integrating the 'fetch.sh' logic inside the spec file? I'll
> gladly offer my server for building the RPMs and I can host them on my
> server too, so we can get our users on track with a good
> experience... I would even build for Factory, but this would most
> likely cause some 'issues' on my side, as inter-obs does not link
> changing base repos that much (it typically end's up in a scheduler
> look).
>
> Dominique
S.
--
Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business
OPS Engineering Maxfeldstraße 5
Processes and Infrastructure Nürnberg
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
No build log
Regards
Chris
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi,
I created packages in my Home project with various distributions and
architectures and it's work fine (RPM's was created).
But when I click on "Goto Repository", this link on a page 404 (page not
found).
Do I forget anything? How do I do to create a personnal repository?
Thanks
--
Daniel Rocher
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
I have a case in my private OBS instance where it looks like there is unnecessary blocking between two packages (with a BuildRequires dependency) in a project when publish and useforbuild is disabled.
My project setup:
Integration (BuildRepositories BR-a BR-b BR-c)
pkgA
pkgB (BuildRequires: pkgA)
...
pkg-n
home:testbuild (BuildRepositories Integration/BR-a Integration/BR-b Integration/BR-c)
pkgA
pkgB (BuildRequires: pkgA, which should be coming from Integration/pkgA)
The testbuild project is set to build off the integration project so that we can do a test build of any individual package. The 'pkgA', 'pkgB' packages in home:testbuild are set to:
<publish><disable/></publish>
<useforbuild><disable/></useforbuild>
This is so that all BuildRequires are always set to pull from the integration project.
What I have observed is that when I rebuild pkgA in home:testbuild, pkgB goes into a "blocking" state unnecessarily. I say unnecessarily because pkgB should be pulling pkgA from the Integration project, not home:testbuild, so there should not actually be a dependency relationship between these two packages. Despite this, obs will block build of pkgA until pkgB has completed its build.
This is somewhat problematic for us because I had planned on doing all test builds in a singe home:testbuild project.
--
Michael
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi,
no status change for an hour since uploaded source.
status still remains: broken
think sheduler is dead.
Regards
Chris
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi,
darix and me decided to also post the results of our weekly meetings to
this list. Here's a summary of this week's meeting.
The task for this week was to add support to the frontend so that desktop
clients like osc can add the oauth specific parameters to the http
"Authorization" header. The ruby library was already able to handle this
and therefore I only needed to do a very small change in our urllib2
OAuthHandler which is used by osc.
Using the Authorization header has one drawback:
- the current flow looks like the following: a client makes an unauthorized
API request, the API sends back a 401 to tell the client that it needs to
authenticate. Therefore the response also contains the following http
header: 'WWW-Authenticate: basic realm="Frontend login" '. This indicates
that the client should use basic auth to authenticate with the API. The
question is how we can tell the client that it could also use oauth? Sending
back something like 'WWW-Authenticate: basic, oauth realm="Frontend login" '
will probably break some clients. Fortunately darix had a great idea:
the client simply tells the server which auth methods it supports. This can
be done by adding a new http header like
'Accept-Authentication: OpenID; OAuth;q=0.8, digest;q=0.7, Basic;q=0.5" '
to each request (q indicates which method is preferred, see other http headers
like 'Accept-Language' for the details). If the API needs authorization it
looks at this header and picks the "preferred" method from this list and sends
back 'WWW-Authenticate: <preferred_and_supported_method>, realm="Frontend login" ' ‘.
In case the Accept-Authentication header is omitted the application's default
method is used (in our case basic auth). Another thing which needs to be
discussed is how the API should behave if the client only accepts methods which
aren't supported by the API (e.g. should the API send back a 401 or 406?).
Apart from thinking about this the other task for this week(end) is to add
an UI for managing oauth tokens etc. The first part of this task is to decide
which tasks the UI should support (like revoking tokens, authorize tokens
etc.).
The next meeting will be on monday to discuss the first results.
Comments, remarks etc. are always welcome:)
Marcus
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi,
I have been working on a project based on Mdv 2009.0 recently, so I hope I can
shed some light...
On Tuesday 23 June 2009 03:58:08 pm Adrian Schröter wrote:
> Am Dienstag, 23. Juni 2009 17:45:05 schrieb Lubos Lunak:
> > On Tuesday 23 of June 2009, Adrian Schröter wrote:
>
> ...
>
> > Still, clearly Mandriva 2009.0 and 2009.1 are not 100% binary compatible
> > either way.
>
This is definitely true. 2009.0 ships python 2.5, 2009.1 python 2.6.. just an
example.
> okay, than we need to import .1 as well :/
> I will take care about this these days ...
>
I am afraid this is going to be needed going forward :/
> > > Prefer: free-kde4-config mandriva-theme-Free
> > > mandriva-theme-Free-screensaver Ignore: libkdecore5:phonon-backend
> > > Ignore: lib64kdecore5:phonon-backen
> > > Ignore: libkdecore5:kde4-l10n
> > > Ignore: lib64kdecore5:kde4-l10n
> > > Ignore: bootsplash:kernel
> > >
Whatever is used in the base distro config, please please prefer phonon over
gstreamer which pulls in lots of stuff... some IMO unneeded. It helps to
reduce the pulse audio footprint.
PA is taboo on my own systems, but that is another debate, for another time.
:-)
> > >
> > > please test if this is working for you.
> >
> > You missed one, otherwise it works.
> >
> > buildinfo is broken... it says:
> > expansion error: have choice for webfetch needed by urpmi: wget curl
>
I have various Mdv versions running in VM's so do not hesitate to ping me on
IRC if you want something tested.
> okay, fixed.
>
> thanks
> adrian
Cheers,
Peter
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hello,
I would like to make it easier to build KDE packages for any RPM-based
distro. I would like to achieve this by requiring just one .spec file with
preferably no %if per distro, where the differencies would be hidden by
macros and such things. The secret plan here is to get people who publish
their KDE apps on e.g. kde-apps.org to use the buildservice for packaging it
and so it should be as simple as possible. I however have trouble with how to
achieve this.
I know I can map differences in package names using Substitute: in prjconf, I
however can't think of a good way how to create the setup per build
repository (distribution). I haven't found any way how to create macros in
prjconf with conditional contents, so that e.g. %_kde4_appsdir would be
different on openSUSE, Fedora and Mandriva as necessary. It appears to me
that the Macros: section is basically interpreted as-is and no substitutions
or %if work there.
I thought also about creating one extra .rpm with just the macro definitions
in /etc/rpm, I could force it in using Requires: in prjconf, but I don't know
how to make sure these macros take priority over macros from the distribution
if there are any with the same name.
I also don't know if any prjconf-based solution would scale well. If many
people package their KDE app in their home repo, they will need to edit the
prjconf. If something in the recommended setup changes, they will need to
edit it again. Is there a way to do some kind of #include
<prjconf_from_other_repo> ?
Any ideas?
--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: l.lunak(a)suse.cz , l.lunak(a)kde.org
Lihovarska 1060/12 tel: +420 284 028 972
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org