October 2006 - openSUSE Build Service - openSUSE Mailing Lists

[opensuse-buildservice] Repositories below http://software.opensuse.org/download/games:/
by Dominique Leuenberger 19 Oct '06

19 Oct '06

Hi everybody, Some time ago (a bit more than a month) I sent this question and apparently there were no answers or no ideas or nobody has seen a desire for it, or I just missed them). So I try again. In case it was replied: PLEASE EXCUSE ME. So: would it be possible to have something like a SuperRepo above the repositories below http://software.opensuse.org/download/games:/ ? This would allow someone to have ALL the categories in his Installer without the need to add them all seperately by category. don't misunderstand me: I like the split in this cattegory, and I think it's important, but it would also be very interesting to have the possibility to subscribe only to one Repository (technically, it IS possible... remains just the question, if it can be implemented on the Build Service). Regards, Dominique

3 3

[opensuse-buildservice] Trying to build helix-dbus-server
by Aaron Bockover 19 Oct '06

19 Oct '06

I'm slowly making progress in my quest to manage Banshee builds in the build service. helix-dbus-server is ... a DBus server that sits on top of Helix/RealPlayer and Banshee uses it as a backend for playing proprietary formats in SLED/SUSE (not openSUSE). The problem is that RealPlayer does not seem to be available under SLE_10. aaron@linux-0790:~/cvs/banshee/osc/Banshee/helix-dbus-server$ osc build SLE_10 i586 helix-dbus-server.spec Getting buildinfo from server /tmp/buildinfo.QCMC6f.xml buildinfo is borken... it says: expansion error: nothing provides RealPlayer Any ideas? Thanks, Aaron --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

4 8

[opensuse-buildservice] new experimental build package
by Ludwig Nussel 19 Oct '06

19 Oct '06

Hi, In order to be able to finally get rid of y2pmbuild I've implemented most of it's convenience features into the build script. I've put an experimental package into the build service if anyone wants to test it: http://software.opensuse.org/download/home:/lnussel/SLES_9/repodata/repovie… The changes will be merged into the canonical package after mls has reviewed them. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ --------------------------------------------------------------------- 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] Re: Repositories below http://software.opensuse.org/download/games:/
by Dominique Leuenberger 19 Oct '06

19 Oct '06

>>> Reply on 19-10-2006 14:59:08 <<<> Am Thursday 19 October 2006 13:06 schrieb Dominique Leuenberger: > > Hi everybody, > > > > Some time ago (a bit more than a month) I sent this question and > > apparently there were no answers or no ideas or nobody has seen a > desire > > for it, or I just missed them). So I try again. In case it was > replied: > > PLEASE EXCUSE ME. > > > > So: > > > > would it be possible to have something like a SuperRepo above the > > repositories > > below http://software.opensuse.org/download/games:/ ? > > > > This would allow someone to have ALL the categories in his Installer > > without the need to add them all seperately by category. > > I am not sure, if a super-repo makes sense, because you will run very > likely > into dependency conflicts and multiple choices for one package. This > would > lead to lots of questions by the package solver. > > However, it would make sense to collect _some_ repos together, IMHO. > Sure, that's about what I meant; in GAMES: for example, you have just some subcategories, but there should usually be no conflicting packages. In no way I wanted to suggest that someone can subscribe to download.opensuse.org and have it all. Nobody should be crazy enough to do something like this Regards, Dominique

1 0

[opensuse-buildservice] No log has been created
by Dominique Leuenberger 19 Oct '06

19 Oct '06

Hi, under what circumstances can it happen that ths BS is not creating a logfile when building a package? It seems the last one I triggered did not get built correctly (SuperTuxKart 0.2.0, as replacement for 0.2; as another release 0.2rc2 appears to be newer). I retriggered it this morning and it seems to create a logfile now. So basically the problem seem to be solved but as I have seen this already more than once, I thought I'd give it a try and ask you about it. Dominique

2 1

[opensuse-buildservice] building a package and get the following error...
by Cameron Seader 18 Oct '06

18 Oct '06

greetings, I am building for SLE_10 and i get the following error checking for AVAHISHARP... configure: error: Package requirements (avahi-sharp) were not met: No package 'avahi-sharp' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables AVAHISHARP_CFLAGS and AVAHISHARP_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. Where can i get avahi-sharp for SLE_10? If i drop in avahi-sharp into my .spec i get an expansion error saying that nothing provides avahi-sharp How can i solve this for SLE_10. -Cameron

2 1

Fwd: Re: [opensuse-buildservice] RFC: BS sends mail on error / after completion
by Dominique Leuenberger 18 Oct '06

18 Oct '06

Forwarded to the list; sorry Adrian! >>> Dominique Leuenberger 18-10-2006 16:32 >>> >>> Adrian =?iso-8859-15?q?Schr=F6ter?= <adrian(a)suse.de> 18-10-2006 16:27 >>> Am Wednesday 18 October 2006 13:56 schrieb Dominique Leuenberger: > Hi everybody, > > Maybe it's planned, maybe I didn't look far enough, maybe... a lot can > be > > Would it bw possible to instruct the BS to send a mail upon completion > / failure of a package to a predefined mail address? > Especially, as sometimes it's taking quiet a long time until it starts > to build (when the BS is busy) and for sue not everybody is looking > every few minutes on the BS screen. > >yes it will be in future. > >However, we want to design this via a generic notification in first place. >This can result in mails, but also in RSS feeds, jabber notice, web side >updates or whatever. Even better like this :-) Looking forward for the new features. Dominique

1 0

[opensuse-buildservice] Delay trigger until I want it
by Dominique Leuenberger 18 Oct '06

18 Oct '06

Hi, I think there was a bad change in the BS: up to now, when I created a new package with a template SPEC File, there was always the BuildRequires remove-me-to-build inside, which I liked a lot. Like this I can uplaod all the files, modify the spec until I think it will be working, remove this REQ and it builds. Today I created a new package and it started right ahead to create the mydummy-1.0-1.1.*.rpm files. What a waste of resources! Can this at least be brought back? Even better would be, if I could decide WHEN the package trigger should start to work. Basically at the beginning, a lot of modifications (uploading files and so on) are to be done and no need to compile the package at all the time. I'd like to see a switch 'Automatic build trigger on/off' in the Webinterface. Regards, Dominique

2 1

[opensuse-buildservice] Building packages
by Aaron Bockover 18 Oct '06

18 Oct '06

Hello, I'm just getting into the build system, trying to set up Banshee. I have the "Banshee" project set up, and first tried to migrate my "libipoddevice" package from autobuild. I first tried to build locally using osc: osc build SLE_10 i586 libipoddevice.spec This started pulling down (slowly) SLE packages, but failed here: Error: No more mirrors to try. Failed to retrieve libstdc++-4.1.0-28.4.i586.rpm from the following locations (in order): file:///var/tmp/osbuild-packagecache/SUSE:SLE-10/standard/i586/libstdc ++-4.1.0-28.4.i586.rpm/ http://software.opensuse.org/download/SUSE:SLE-10/standard/i586/libstdc ++-4.1.0-28.4.i586.rpm http://api.opensuse.org/rpm/SUSE:SLE-10/standard/_repository/i586/libstdc++ I then committed libipoddevice to the "Banshee" project and clicked "Trigger Rebuild" in the web interface. It has been scheduled there for almost 4 hours I think. So my questions: a) Any reason why libstdc++ can't be pulled down? (would be nice if this were fixed) b) Why is it taking 4 hours to start building libipoddevice in the build service? What if it comes back failed after it's finally started to build - do I have to wait another 4 hours for my second try? This seems like an insane amount of time - and libipoddevice is a very simple package to build. I'm worried that when I actually get to Banshee itself, the process will take hours and hours and hours. c) Maybe there's something else I should be doing altogether? I'm completely new to the build service and am mostly just poking around, although at the same time I would very seriously like to host Banshee's builds inside the build service. I'm dead set on providing easy to use and updated packages for Banshee for SUSE/SLED at the same time I release my tarballs. Thanks in advance for the insight and response. Regards, Aaron Bockover --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

4 5

[opensuse-buildservice] Re: [RFC] Release numbers and the Kernel project
by Adrian Schröter 17 Oct '06

17 Oct '06

Am Sunday 15 October 2006 21:32 schrieb Andreas Gruenbacher: > On Sunday 15 October 2006 13:53, Jan Blunck wrote: > > Therefore my proposal for fixing this issue: a buildservice package link > > should inherit the release number from its source package. All changes > > inside the linked package (additional patches, files, ...) should be > > added to this release number. I would like to see a solution, which would work also without a special hack inside of the build system. The problem is currently caused by the fact that the retrigger of a source link does not work yet within the build service. This means, kernel-default does not yet triggered, when update kernel-source. It could be that this particular problem disappears by accident when this is fixed (since all packages do always get triggered and the release number get increased when changing the source. However, there is not guarantee that this will always work). For some rational behind this, usually you have the version number to tell, if a package got significant changes and is still compatible. This is different for the kernel. However, every release number change does already make it complete incompatible. I do not want to discuss this now, but we need to keep it in mind when we speak about this situation. Since this affects also the kmp module packages, I want to repeat the current state of discussion. Please correct me, if I am wrong ;) The kmp modules build could check against which kernel version+release they are building against (means, they do not use the version+release from their own spec file). This could be done via a "rpm -q kernel-source" call during the build. Pro: * This works also outside of any specific build system. * You can update the drivers and updated versions get also a higher release number. Contra: * you can not see anymore if all kmp packages do fit for the kernel via the version+release number. (but this information could be exported in a different way). > I don't understand what you mean exactly: do you mean that when there are > changes other than plainly linking the package, then the release number > should be <linked-to-package-release-number> + 1, and if there are no > changes, the package should keep the original > <linked-to-package-release-number>? > > I'm not sure that we want to hardwire the way how release numbers are > computed for linked packages; I could imagine that we sometimes want to use > the same release numbers for the linked-from and linked-to packages, and in > other cases we want to keep the release numbers independent. actually, the concept of hardwire release numbers do break the idea of having the guarantee that they get always increased in a proper way by the build system. So, I do see more problems introduced than solved by this ... > In the kernel case in particular, we need to associate each particular > check-in (i.e., each set of package sources) with a unique identifier; this > is sufficient so that all the packages will refer to the correct paths > in /usr/src/* and /lib/modules/*. Without it, building external kernel > modules would break. right, but IMHO you can find these pathes during the build also without to use the version/release number from the kernel flavor or kmp module spec file. > This unique identifier could be the release number as we do in Autobuild, > or it could be some sort of source release number: The build service > release numbers are of the form x.y, where x gets incremented per checkin, > and y gets incremented per build. We could the x part in the kernel. > > Beyond this necessary minimum requirement, it would be nice to fully > synchronize the release numbers (source and build), so that all the kernel > packages that "belong together" can easily be identified without having to > know that the ".y" part of the release number can be ignored for this > purpose. I'm not totally convinced that this is the best idea though; > keeping a build number has other benefits. We can ignore the .y part without any problem. However, you still have a problem when you hardwire the release numbers for the case, when you only edit a kernel flavour package (kernel-default for example). Currently this problem got hidden of the fact that also in this case all packages get rebuilded. But imaging what happens when this does change. You would get a newer package with the same version and release number .... -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian(a)suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

3 4