June 2009 - openSUSE Build Service - openSUSE Mailing Lists

[opensuse-buildservice] Versions in prjconf Substitute
by Lubos Lunak 29 Jun '09

29 Jun '09

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

3 6

[opensuse-buildservice] Mandriva2009 problems
by Lubos Lunak 29 Jun '09

29 Jun '09

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

2 6

[opensuse-buildservice] Re: [opensuse-factory] Plans and Issues for ATI fglrx Driver for 11.2?
by Susanne Oberhauser 28 Jun '09

28 Jun '09

"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

1 0

[opensuse-buildservice] build/27 dead
by Christian 27 Jun '09

27 Jun '09

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

1 0

[opensuse-buildservice] "Goto Repository" linked to 404 error
by Daniel Rocher 27 Jun '09

27 Jun '09

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

1 1

[opensuse-buildservice] unnecessary blocking between packages in a project.
by Michael_E_Brown＠Dell.com 27 Jun '09

27 Jun '09

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

3 3

[opensuse-buildservice] x86_64 sheduler dead ?
by Christian 27 Jun '09

27 Jun '09

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

2 2

[opensuse-buildservice] GSoC - summary of this week's meeting
by Marcus Hüwe 26 Jun '09

26 Jun '09

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

1 0

Re: [opensuse-buildservice] Mandriva2009 problems
by mrdocs 25 Jun '09

25 Jun '09

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

3 2

[opensuse-buildservice] Common place for configuration of different repositories/distributions?
by Lubos Lunak 25 Jun '09

25 Jun '09

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

2 1